Skip to main content

Software Development Lifecycle

Our software development lifecycle consists of the following stages:

  • Planning & Requirement Analysis
  • Design & Architecture
  • Development (Continuous Integration + Shift Left Testing)
  • Automated Testing & Validation (e2e & Synthetic Testing)
  • Continuous Delivery (CD)
  • Monitoring & Feedback

We are approaching this process in a modern and pragmatic way, using tooling and practices that enable us to build secure, and reliable software at pace. This requires us to try to automate as much of this process out with appropriate tooling and apply an alternative risk model, instead of more traditional risk models like the three lines of defense.

Planning & Requirement Analysis​

When discussing new features we build out Epics in Jira, and assign tasks to that epic, at this stage we discuss the requirements and plan how we can implement the feature, considering security implications, ways of testing, and deployment and try to size and document the different tasks needed to deliver the feature.

Design & Architecture​

We initially discuss this when a feature is discussed, if any changes are needed we either discuss and design this in person, or discuss it asynchronously with an RFC. RFCs are used to propose a solution and encourage conversation before an architecture decision is made. Once the architectural design has been decided upon, we then ratify them with Architecture Decision Records, as described by Michael Nygard. All of this sits next to the code that is to be changed, or in the tech-documentation repository.

Development (Continuous Integration + Shift Left Testing)​

We follow the github flow development model and follow Continuous Integration practices. This means that we propose changes through pull requests at which time we have thorough peer reviews to validate quality and security before merging in to main. Furthermore, we try to follow shift left testing principles and run multiple types of tests and checks (linting, code quality, security etc) both before committing files, and upon commit. This enables us to catch issues early on in the development cycle without having to have independent reviews later on in the process.

Our development process includes:

  • Staging changes on short lived feature branches and creating pull requests against main
  • Automated Testing: Running automated tests, linters, security scanning both locally (pre-commits) and in CI on every commit
  • Automated Builds: We build our software and artifacts on every commit
  • Build Automation Tools: Utilize GitHub Actions as a CI/CD system to run these checks
  • Frequent code integration: Merging small pull requests often and deploying them to production
  • Code Quality Metrics: Measure test coverage of the code and consult codeQL output

Automated Testing & Validation (e2e & Synthetic Testing)​

We have extensive e2e testing in place for the frontend application using browser automation tooling (playwright) and standard golang testing tooling. These automated tests cover our application workflows and happy paths, ensuring that features continue to work when we make any changes.

We also have some synthetic tests running in checkly to ensure our live systems are functional at any time, and any issues are caught before a customer catches them.

We do carry out some manual tests when we have small changes that are not covered by our tests or they are an unusual edge case that is difficult to automate. We do aim to automate tests wherever possible and reduce bottlenecks and manual actions when releasing software wherever possible.

Continuous Delivery (CD)​

As we follow GitHub flow, once a change lands in main, we have CD pipelines that facilitate the delivery of software to production through several environments (dev, staging, demo and production) and stages in order with pre-defined gates. Our e2e tests run, as well as our synthetic tests, which give us confidence in progressing changes through our environments. We have manual gates to deploy to Demo and Production so that we can manually validate any changes if necessary.

Monitoring & Feedback​

We utilize Datadog as an all in one monitoring platform which collects logs, metrics and traces, and integrates with third party platforms (AWS). From there we build threshold monitors which can trigger alerts, these are routed to incident.io where we are alerted via sms, phone and notification. We also route our checkly alerts to incident.io. Our oncall and incident response is outlined in the incident management section.