Skip to content

Instantly share code, notes, and snippets.

@MatMoore
Last active June 7, 2019 18:54
Show Gist options
  • Save MatMoore/8eef06ba696b464929cf5623939c4dc3 to your computer and use it in GitHub Desktop.
Save MatMoore/8eef06ba696b464929cf5623939c4dc3 to your computer and use it in GitHub Desktop.
Modernisation patterns

Adopt a modern build tool

Context

  • 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

Problem

  • 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

Solution

  • 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

New context

  • 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

Introduce Continuous Integration

Context

  • 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

Problems

  • 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

Solution

  • 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

New context

  • 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment