DevOps Delivery Pipeline

A delivery pipeline which is also known as a deployment or build pipeline, is how a story from a product backlog makes its way through to development, testing and deployment to production.

Developer writes code and fixes bugs. The coding activities can be reviewed by a peer developer which is called peer reviews or done by two developers working together also known as Pair Programming.

Developer also writes unit tests and integration tests or API tests. In case of “front-end” developers, there will be Javascript unit tests or JSUnit tests. Any new code which contains logic should be unit tested.

The above testing activities can also be supported by testers where they can help with reviewing the test cases in particular integration and API tests.

Because unit tests are very quick to run and that we want to only commit good code to the repository, unit tests and JSUnit tests are run on the developer’s local environment.

Once the unit tests have been reviewed and passed on the developer’s machine, the developer commits the code to the repository

As developers are building new features, QA or Testers work in parallel to write the automated acceptance tests for the new features. Here, dev can also participate and help the non-technical testers to write automated checks.

 

Once the developers commit their code to the repository, (remember there are multiple developers working on one or more project) the commit will trigger an automated build where the project is built and artifacts are created.

First unit tests are run. Once all unit tests are passed, then integration tests are run.

It is often the case that integration or API tests require custom data from different sources, such as databases and/or 3rd party APIs. For this reason, it is best to mock any external connections so that we could be free from any downtime or unavailable services and fully focus on the tests.

Once all the unit tests and integration / API tests have passed in Jenkins build, and automated deployment job is kicked off to deploy the latest artifacts into an integration environment.

In the integration environment, the new code is integrated with existing production code, hence the name integration. When multiple teams exist, it is important that each team have their own integration environment so that the execution of the automated checks are not affected by other teams’ deployments.

Once the deployment job is complete and the application is deployed, first an automated smoke test pack is run to make sure the application is up and running and can be accessed, then if everything is OK, we run a full suite of automated acceptance tests for the new functionality and existing functionality, i.e. new and regression.

In integration environment, the application points to real data and services and we will run a mixture of API and UI automated tests against the application.

The next step in this delivery pipeline is a manual deployment to “QA” environment.