What Are the Components of Sustainable DevOps?

Build and Release Pipeline

DevOps believes in the automation of builds and deployments. Conceptually, a release pipeline is a process that dictates how you deliver software to your end users. In practice, a release pipeline is an implementation of that pattern. The pipeline begins with code in version control and ends with code deployed to production. In between, a lot can happen. Code is compiled, environments are configured, many types of tests are run, and finally, the code is considered done.

By done, we mean that the code is in production. For some organisations, a release pipeline strategy and structure needs to cover services, database, web, and mobile application components, and includes:

• Binary package consumption
• Continuous integration builds
• Package publishing
• Automated testing
• Continuous delivery

It is important to recognise that mobile deployments are different than web and server deployments. How you get your mobile app out for feedback is different than the process you use to obtain server application feedback.

Binary package consumption

Package management allows you to reuse trusted components. An example is NuGet feeds. If you consume and reuse packages consistently, then you can keep your application fresh as those packages are updated. This is particularly important for security and compliance as the packages can be scanned, uniquely identified, and, in the event of new vulnerabilities, automatically updated.

Packages should not usually be included in version control because they may significantly increase the size of version control repositories. Better to have the packages stored in package management, such as internal NuGet feeds.

Continuous integration builds

Continuous integration builds are builds that are triggered upon every check-in of code. They should be quick to complete and include automated tests (such as unit tests). They may or may not drop artifacts upon completion.

Package publishing

Package publishing may tie into binary package consumption. You should use a version that matches the build and deployment number for full transparency (if a deployment breaks, you should be able to find the matching package quickly). The package should be hosted somewhere accessible by projects, such as NuGet feeds.

Automated testing

Testing could include unit, integration, automated UI, web performance, and load tests. Tests should be able to run independently and as often as possible without breaking, such as in continuous integration builds or automated deployments.

Continuous delivery

Continuous delivery means that deployments are triggered automatically after a build completes. The process should include picking up a compiled package of code, setting the target environment in the desired configuration state, and deploying automatically to environments. It may include approvals into QA or production environments.

Backlog

One of the primary cultural shifts required for adopting DevOps practices is at the backlog level. The novel The Phoenix Project designates the following types of work:

• Business projects – work that comes from business initiatives.
• Internal IT or engineering projects – infrastructure/operations projects from a business project, or internal improvement projects. These items should be tracked in the same backlog.

Note: To continuously improve the system of work and adaptability, it is recommended that at least 20% of development and operations teams’ time is allocated toward nonfunctional requirements such as security and infrastructure, among others, to make the process significantly better and more stable. If time is not allocated to this work, technical debt will accumulate and create more unplanned work.

• Unplanned/recovery work – operational incidents tacked onto planned work, which might cause bottlenecks and confusion with handoffs. This work can also cause long lead times with high utilisation and it is often the result of not removing technical debt or improving practices.
• Lead time is the cycle time from when a team starts writing code to its first successful deployment in the production environment. Lead time is considered a measurable metric that could be improved with DevOps practices.

Version Control

Most organisations use some form of version control to manage their source code. However, not all organisations use version control effectively. Two version-control strategies that are sometimes overlooked are:

• Setting up an appropriate branching strategy.
• Enabling transparency by linking work items to code.

One approach is to have a single branch (such as the master or main branch) that gets built in an automated continuous integration build, then deploys to a development environment upon every commit or check-in that occurs to the branch. This way, it is easier to know which changes have been released into the development environment, and eventually, into production.

The changes automatically deployed into the development environment will then get promoted or copied to the test or staging environment, and then into production. The same compiled code will get deployed to production so that there is never a situation in which unchecked code gets promoted to production. Before deploying to any environment, it is important to ensure that the changes made align to the business strategy.

Connecting work to code

An easy way to verify that deployed code has value and is related to work on the backlog (rather than code that does not tie back to any work items) is by linking work items to code changes so that metadata is kept with the changes, and then with build and deployment. By connecting work in progress to code, you can validate feedback from users and the changes that were made in the code.

Some organisations use different branching strategies depending on the type of application being deployed, the degree of coupling, the organizational structure, and the deployment cadence. A general rule is to promote the simplest branching strategy possible to keep maintenance low and sustainability high. If you have long-lived branches that are infrequently merged, you accumulate a subtle form of technical debt.

If your organisation does not currently use version control, it is important to start using it to version your code. A good way to start is to learn about Git repositories, and distributed vs. centralised version control.

In DevOps organisations, infrastructure is treated in the same way that software code is treated. Infrastructure as Code (IaC) is the management and provisioning of machines through code. This code is versioned in public or private repositories and shared across individuals and teams to enable more collaboration while keeping a track of changes using version control systems like Git.