Continuous delivery (CD) means building immediately every time you commit your code, and you can deploy your build into production. This article will share some of the techniques and experiences associated with Continuous delivery.

Automation

Automation is essential to a sound CD pipeline, and we should replace manual work with automation whenever possible to achieve maximum benefit.

In the past, our development team might have done tests, some manually, some automatically, before releasing code into production. But in the case of continuous delivery, code is tested every commit, so the best approach is to “automate everything that can be automated,” and not just the development team.

Automation of all important parts of software is necessary

  • Tests – Unit Tests, integration Tests, UI Tests, regression Tests, performance Tests…
  • Database installation, backup, and recovery
  • Installation and testing of products and their dependencies
  • Code documentation and user documentation

Depending on our product, there may be many other automatable parts, such as cloud-based products that automatically configure the infrastructure.

Commit often, Commit soon

The second important foundation of the CD process is the ability to “commit often, commit as soon as possible.” Fast feedback cycles can make a huge difference when delivering software.

Unfortunately, the Big Bang development approach and deployments is still the norm. In this way, it is common to release large amounts of code into production every few months at once.

Introducing a lot of changes into your code and deploying them to a production system can have unintended consequences. It’s hard to know exactly what’s going on, and it’s difficult to diagnose. Large systems that are updated this way have a hard time getting back to working state because you can’t easily roll back.

Continuous delivery requires that you frequently integrate changes with the main branch. Every time you change your code, push the changes to version control.

If we don’t commit all day, it’s generally impossible to know exactly how our commit fits into the rest of the system, or if it has broken anything. If we were using a version control system, developers could switch to code at any given point in time in the past.

Another positive result of frequent submissions is that we can get feedback on the status of the project much faster, we can quickly see that a solution is going in the wrong direction, and if something goes wrong, we only need to debug some potential parts. Also, don’t forget that meaningful submission notes are important!

When developers work in isolation from each other for long periods of time, implementing CDS can be a near-impossible task. Development cycles lasting several months are not uncommon in large companies. When development happens this way, there is a lot of testing at the end of the development phase, which means that for quite some time we don’t know if the application is working properly.

Avoiding this uncertainty requires developers to commit their work frequently and make changes available to others as soon as possible. This is important in large teams, which makes merge conflicts and other issues caused by large commits less frequent and easier to resolve.

Developers and Operations

Advanced software development companies generally follow at least part of the Agile/Scrum approach. For example, one of the rituals of Scrum is for the team to have a daily discussion about what they did yesterday, what they are going to do today, and what’s going to be difficult, in order to keep the team informed of the work being done.

An easy way to improve the development team’s knowledge of the production environment is to involve operations engineers so that the development team can better understand what operations does.

In the long run, we need DevOps to keep development and operations from becoming two islands.

Production Environment

The final frontier for CD is deployment into production. No production deployment is required for each commit that generates the code base, but each build needs to be production-ready.

Most development teams have little or no access to the actual production environment, hardware and software specifications, configurations, security rules, and so on.

The first step to improving this situation is to create a temporary environment that is as close to the real production environment as possible.

Breaking Monoliths

A common obstacle to effective implementation of CD is overcoming the “sluggishness” of the all-in-one architecture code base. Slow builds, fragile code bases, complex code and architectures are some of the common problems.

The common approach is to rebuild the entire system, but the common approach involves a lot of time, resources, and money, as well as technical challenges.

For companies that don’t focus on software development, it’s much more difficult to get approval from management because it requires extra budget and energy to allocate to what may be a marginal gain.

For other companies that are more focused on software, rebuilding the entire solution may be the best approach in the long run.

Our suggested approach to getting started is to split the code base into multiple repositories, each focused on a smaller subset of the overall product. Each of these smaller repositories should be self-contained, with its own build scripts, tests, and so on.

As a result, the CD process can be implemented more quickly without the need for a complete overhaul of the system. In the long run, these individual repositories should be further subdivided into smaller parts using a microservice architecture approach.

About Rainbond

Rainbond is an “application-centric” open source PaaS that deeply integrates kubernetes-based container management, ServiceMesh microservices architecture best practices, multi-type CI/CD application building and delivery, multi-data center resource management, and more. To provide users with cloud native application life-cycle solutions, build an ecosystem of interconnection between applications and infrastructure, application to application, and infrastructure to meet the requirements of agile development, efficient operation, and lean management required to support rapid business development.

  • Web site
  • Github
  • Yards cloud
  • The demo environment
  • The document
  • community
  • Wechat group: Add wechat “Zqg5258423” and accept invitations to join the group