The ERP system that we use is Banner. There are some big architectural changes that we’ve been adopting. This translates into some changes on how we do development. We will try to summarize them in this post.

Revision Control

We were using SVN to manage code that our vendor provided. The code is now provided via git repositories! This meant that we needed to store these git repositories locally. Other units within Information Services in the past used GitLab ( https://about.gitlab.com ) . GitLab is a good open source solution, but our previous experience with it showed us that the monthly updated usually broke some aspect of functionality and the upgrades were painful due to rails / ruby version updates. We went with GitHub Enterprise ( https://enterprise.github.com/home ) . 

We talked to another couple of schools that used GitHub Enterprise (for other types of development) and they were very happy with the UI and maintenance. Our experience with upgrades to GitHub enterprise have been painless. Features and changes to the GitHub platform first appear in public github.com and after a couple of months we’ll see them come to an upgrade in GitHub Enterprise. 

The change of svn to git is not an easy change for our developers. The change from a centralized server such as svn where we mostly used TortoiseSVN as a client to a decentralized system such as git is a big change. We tried using Code School to provide devs with access to great git tutorials. The issue was that due to work related commitments and devs not actively using git, the training wasn’t effective. Our next plan of action is to have group git exercises in a frequent basis. This will expose developers to using git more frequently and use the new scm features that a decentralized system such as git provides. For GUI clients we recommend using SourceTree ( https://www.sourcetreeapp.com ) and within Linux we use the command line since that’s easier.

Development Environment

Our developers use Windows for development. When we started to experiment with Banner XE development, we ran into roadblocks. Having to manage different versions of Java or Grails in Windows is not easy. In *nix environments, we have tools such as SDKMAN ( http://sdkman.io ) to manage the versions of JVM tools. It took us days to get Grails applications and their dependencies properly running in Windows. That’s when we realized that Windows could work, but trying to replicate this setup in each developer workstation was going to be a nightmare. 

To make lives easier we used VirtualBox ( https://www.virtualbox.org ) and created a VM using Ubuntu. In this VM, we setup the various Java and Grails dependencies to build Grails Banner applications. By having a single VM, we could setup the dependencies and configure the JVM tools once and all the developers could leverage a single installation. We had a Google doc that specified how to setup and configure the dependencies. It was several pages long and mostly due to screenshots in Windows. On the other hand, the Linux instructions were much shorter and could be scripted.

Using VMs was great, but we started to run into some memory problems. Our development machines were about 4-5 years old with 16GB of RAM and non-ssd hard drives. The grails applications that we are dealing with easily require 3-4GB of RAM each. We also use Intellij IDEA Ultimate within VirtualBox. We found that Intellij IDEA worked properly within VirtualBox. To be on the safe side, we give a total of 6G of ram to VirtualBox. This meant that developers couldn’t run many applications in their machines. Web browsers use a lot of memory and trying to run two VirtualBox VMs concurrently wasn’t possible.

To support development, developers got new machines. The new workstations have 32G of ram and an SSD. A new CPU and GPU were also part of the upgrade, but we didn’t find them to be a constraint with the previous machines. The SSD provided some improvements for Windows, but once VirtualBox is running the SSD doesn’t make a huge difference. I would still recommend to others to upgrade to a new SSD and RAM if possible. It is a very cheap upgrade and you will run out of RAM.

Automation

In order to support the updated development workflow, we are using Jenkins ( https://jenkins.io/index.html ). The ESM tool provided by our ERP vendor leverages Jenkins as the underlying technology. From talking to our DBA, ESM only provides us with admin level access so it’s not something that we could easily allow devs to use, yet. We do have ESM installed, and our DBA uses it to fetch code from the vendor.

Since we have non grails based development it made sense for us to stand up a separate instance of Jenkins. We are leveraging Ansible ( https://www.ansible.com ) to setup the Jenkins, its dependencies and jobs. By using Ansible, we are able to test changes to Jenkins locally via Vagrant ( https://www.vagrantup.com ) in our workstations. We can go from a bare VM to start compiling an XE Grails application (using a jenkins job) within 5 – 7 minutes. 

Workflow

So far we haven’t made any custom changes to the codebase. 

1. A Jenkins job checks daily if a new git repository is available from the ERP vendor. If there is a new one, we create a new repo in github enterprise
2. Daily we update our GitHub Enterprise repos with any new commits, branches and tags from the vendor

The development workflow that we plan to use is the following:

1. Use three git branches that mirror our instances for each application. One environment is production and the other two are development / test.
2. When a developer wants to make a change to either the development or test environment, they would create a feature branch. The feature branch’s name is a ticket-id (from our bug tracker) and two / three word description of the change. This allows us to track a change / back to a developer and why the change is being made.
3. We want to commit early and often to the feature branches. Once the code is ready, we’ll use GitHub’s Pull Requests to do reviews. 
4. Jenkins jobs can be leveraged to perform checks on the code.
5. Once the code is ready to be deployed to either the test or dev environment, a Jenkins job will generate a war file for our DBA.
6. Our DBA then uses ant scripts provided by our ERP vendor to deploy the WAR file to Tomcat.

The advantages of using Jenkins to compile the code is that we make sure there are no local code changes or dependencies in a developer’s workstations needed to compile code and not present in GitHub Enterprise. All war files are compiled in the same manner (JVM version, dependencies, etc). Naming of artifacts is consistent and Jenkins can send notifications when builds fail. Developers can review previous builds, generate new war files, and examine failed builds.

Next Steps

Some of our next steps and improvement areas:

• Right now we are using Google docs to document steps for developers. These need to be improved since at the time we were heavily using Windows for development.
• If you are coming from SVN, moving to git is a big change. We plan to do git exercises as a team on a weekly basis. This will help get our developers familiar with git commands, merging, branches and dealing with git conflicts.
• As we start to make changes to the vendor supplied code, we need to figure out what version of a grails application we are running. We need to keep track not just of the vendor’s base version, but our commits / changes. We’ll use jenkins to name war files in a way that includes the environment, vendor version and our local commit sha1.
• Containers are the next major step for virtualization. We plan to explore how we can best run WAR file in containers for development purposes.