Skip to content

Continuous Integration and Continuous Delivery (CI/CD)

For the FCP Platform, Jenkins is used for CI pipelines, whilst Azure DevOps is used for CD.

Originally the FCP Platform was primarily hosted on AWS where Jenkins was prescribed as the CI/CD tool. However, as the platform has migrated to Azure, Azure DevOps was prescribed as the CD tool. Jenkins is still used for CI pipelines as it is a well established tool within the programme and redevelopment of the pipelines in Azure DevOps would be a significant undertaking.

Continuous Integration (CI)

FCP adopt a "shift left" approach to security and quality, meaning that security and quality checks are performed as early as possible in the development lifecycle. The CI pipeline is designed around this principle and looks to provide fast feedback to developers and testers prior to merging code to the main branch.

Feature branch development allows for small changes to be made and tested in isolation. This is supported by the CI pipeline which will run a subset of tests and checks on a feature branch build. The pipeline will also provision a dedicated environment for the feature branch build to be deployed to, allowing for a more comprehensive set of tests to be run.

In order to avoid duplication across all microservices, a common Jenkins pipeline has been created.

Note that a feature branch must have an open Pull Request in order for the CI pipeline to run.

Supported technologies

The CI pipeline supports the following technologies:

  • Containerised Node.js applications targetting Azure Kubernetes Service (AKS)
  • Containerised .NET applications targetting Azure Kubernetes Service (AKS)
  • Helm charts
  • Azure Functions
  • Docker images
  • npm packages

Pipeline stages

Build steps

The steps for a feature or main branch build are more or less the same. The most significant difference is there is no feature branch deployment for a main build. Instead additional build assets are created ready to be promoted to higher environments.

Below shows the pipeline steps for building a Node.js application targetting AKS. The steps for other technologies are similar. Anywhere CUSTOM INJECTION is shown custom steps can be injected.

Some steps are optional depending on the content of the repository.

  1. Validate semantic version of package
  2. Lint Helm chart
  3. npm Audit vulnerability check
  4. Snyk vulnerability check
  5. CUSTOM INJECTION
  6. Build test Docker image
  7. Provision dynamic infrastructure for feature branch and to support integration tests
  8. CUSTOM INJECTION
  9. Run containerised tests (linting, unit, integration, contract)
  10. CUSTOM INJECTION
  11. Publish contracts to Pact Broker
  12. SonarCloud static code analysis
  13. Build production Docker image
  14. Publish image to to Azure Container Registry
  15. Deploy image to dynamic AKS namespace (feature branch build only)
  16. AXE accessibility tests (optional)
  17. BrowserStack containerised UI and compatibility tests (optional)
  18. OWASP Zap security tests (optional)
  19. JMeter performance tests (optional)
  20. Publish Helm chart to AZure Container Registry (main branch build only)
  21. CUSTOM INJECTION
  22. Create GitHub release (main branch build only)
  23. Clean up build specific dynamic infrastructure
  24. CUSTOM INJECTION

Clean up steps

Once a feature branch is deleted, the clean up process will automatically run to remove any dynamic infrastructure.

Continuous Delivery (CD)

Once a feature branch has been merged into the main branch, the CI pipeline will automatically run to package the assets and deploy the application to the Sandpit environment. Assuming the Sandpit deployment was successful, Jenkins will then trigger Azure DevOps to deploy the application to the higher environments.

ADO will deploy the application to the following environments once the previous environment has been successfully deployed to:

  • Development (automatic)
  • Test (requires approval from anyone in the team)
  • PreProduction (requires approval from anyone in the team)
  • Production (requires approval from CCoE and an Request for Change (RFC))

Note that some of the more mature teams in FCP have approval to run their own changes to Production using a standard change.