Skip to main content

Development Lifecycle and Production deployments

  • Business Planning
  • Workshop and Design
  • Developer Planning
  • Build
  • Testing/QA
  • Deploy
  • Ship

Business Planning​

We work with an agile methodology and divide work into Slices. These slices can contain one or two big features and several smaller features identified by business. Slices are divided into 8 week cycles with a two week period between slices where we monitor and iron out any bugs.

Workshop and Design​

Before a feature can form part of a Slice, stakeholders will plan out the feature and determine what the requirements are. Several workshops are held where designers and engineers are included, and we go into further detail on the feature, establish what is required and rough estimates are given. This process is documented using Miro which is available to the entire organisation.

Developer Planning​

Once workshops are completed and most of the details are fleshed out, a feature will form part of a Slice. Developers will then usually whiteboard through an Event Storming session. All requirements and details are fleshed out in a Github issue.

Build​

Based off the github issue/s, we divide the work into units and assign them to individuals. All work is unit tested, code reviewed and run through a CI server. Please see our Github workflow in the Source control section.

Deploy​

QA testing is done in the production environment when deployed, but isolated to QA testers only. We do this by exposing api calls to a QA client only, then once happy, we can roll out to everyone. Testing in production is not suitable for all companies, however, we do this because we are confident in our architecture. It is also important to note that when deploying, nothing is rolled out unless unit tested and code reviewed.

Here are a few great articles on why you should be testing in production:

But to highlight why we go this route:

  • Our tools are resilient and fault tolerant, we can recover from unexpected events without loss of functionality and data.
  • We have great production monitoring tools (LogDNA and Sentry) and we can apply fixes as they happen.
  • Testing with production data gives us better insight into features we roll out and how the system actually performs.
  • QA/Staging environments often don't pick up issues you wouldn't pick up with unit testing. It's also a different environment with different metrics and monitoring and not a true reflection of what happens live.

In future we would like to set up Canary deployments, which would be rolling out a new feature to a select few clients before rolling out to everyone.

Ship​

Once QA testing is done we roll out to everyone. Code is then tagged with a version number and the Github issue is closed.

Monitoring​

Monitoring and uptime is monitored daily by the engineering department. All errors are sent to us on Slack as and when they happen and we resolve them immediately.

Additional info​

We have a weekly status meeting with any stakeholder who is interested. Here we give an update on the progress we've made for the week, what - if any - impediments were experienced, and if we have anything new to show, we demo it.

Product development has a lot of what ifs and that's unexpected moments, but this should give a rough overview of how work is delivered.