CI/CD Pipelines

Branching Strategies/Feature Branch

This lab  aims to help non-technical people like non-technical product managers, project managers, and executives to support their engineering teams on the path to building better high-quality products, keep high delivery pace and avoid unpleasant surprises for your valued customers.

The continuous delivery process starts with keyboard strokes of your engineering team and ends with the experience your customer has with the product. The goal of continuous delivery is to shorten the time and avoid mistakes between these two points in time. A well-oiled mature continuous delivery system takes deployment management burden off your engineering team, allowing them to focus on engineering and product build.

The very first and most important step towards continuous delivery is a centralized place to store and share code. Code is the key (and sometimes the only) outcome of software engineering activities, and this code needs a place to live. This place is a common and shared environment that everybody on your engineering team knows and uses every day. You can think of a code repository as a Google Drive or Dropbox for engineers to share and work on the code. A great place to start your journey to build continuous delivery is to introduce a code repository in your organization if you happen not to have one.

 

The code repository of choice is most often available through providers like github, gitlab or bitbucket to name a few [1]. These providers offer powerful free tiers that will serve you for a long time until you will see a need to pay for premium features. Check-in with the team if they have any preference or prior experience before choosing any specific platform.

The code repository is an integral part of any software development process and should be adopted by any technological company early its days. The code repository makes it possible for engineers to store and share code, track revisions, and incoming change requests.

Review, inspect and test every product change

All changes to your products are made by humans, and humans are prone to making mistakes — which is not bad, but rather how things are. And while we can all ask our colleagues and teams to write bug-free code — bugs still do slip through the cracks. To minimize the risk of getting bad product changes into our customers’ hands we can introduce a couple of additional hops that the change needs to jump through. First, we can employ computer programs (automated tests and various code analysis tools) to be impartial judges of the quality of changes we introduce. Second, other people on the team might be able to spot issues or deficiencies in the change the author overlooked (manual review process). Both of these steps ideally would be triggered automatically on every code change.

 

Most of code repository providers (including github, gitlab and bibucket) provide tools to build continuous delivery pipelines. A pipeline is a set of predefined steps that run automatically following a particular event (code commit, time schedule, manual trigger). An example of a pipeline definition could be “on every commit, build the product and run automated tests on it”. Configuring and streamlining pipelines will require some time and iterations but will quickly bring the reward of stable products and happy customers.

One of the options how the process of accepting new code change into repository can look as following:

1.    Submit new code change. The author of a code change submits a change request to the code repository. At this stage, code is placed in a separate “sandbox” (also known as a pull-request, or change-request). This is done to prevent potentially harmful changes to making their way into the main code base unverified.

2.    Trigger automated tests. On changes submitted to the code repository, pipeline executes tests that validate basic functionality, compliance with code style, and security standards. If the pipeline fails, it notifies the author of spotted errors and waiting for the author to provide a fix.

3.    Open a code review request. At the same, either automatically after smoke tests or on author request, the code management system opens a code review request where teammates can check out the change candidate, leave comments, improvement suggestions or ask questions. Once all involve satisfied and approve a request — change can make it to the next stage. 1–2 people to look through the code is usually enough.

Once steps above are completed, your code is ready to be merged to the main codebase where it will slowly progress through a series of stages and additional verifications.