- The existing build scripts used ant
- We had multiple build artefacts, ant scripts and property files
- A lot of configuration was targeted at a specific environment and OS (windows)
- Dependencies were bundled with the project
- The build scripts were difficult to understand
- Ant is not a technology we use for other projects so developers are unfamiliar with it
- Dependency management was harder than it needed to be
- We created new build scripts in Gradle
- We checked the build artefects produced are identical by listing the contents of the jar/war files and running a tool to compare binary compatability of the packages
- Build files are a lot more concise
- Dependencies are declared in one place and are pulled from public maven repositories at build time, in line with the 12 factor app
- The app was built from a long lived development environment
- Developers each had their own configurations for building the software
- A different artefact was built for each environment
- Code branches were long lived, and changes got batched up into scheduled releases
- We had some automated tests, but many of them didn't run
- There was no immediate feedback when developing changes
- The team were not confident that the artefacts they were releasing contained what they thought it did
- The master branch cannot be deployed at short notice so we had to make hotfix branches and keep track of them
- We created a CircleCI configuration that runs the gradle build
- The build publishes war files
- We reviewed the tests, fixing some that didn't work and deleting others we didn't need, so the entire suite runs in CI
- Master contains code that has passed CI and we're happpy to release at any time
- The tests give us some confidence that a pull request hasn't broken existing functionality
- In the short term we intend to build environment specific artefacts from CI and deploy those, which will make it easier to see the link between a deployed artefact and the source code it was built from