Unit Testing Is Not the Only Answer to Continuous Delivery

To make continuous integration and delivery (CI/CD) a reality, companies must review their internal processes and rethink how they approach the software delivery lifecycle. Past listings and reviews are not the way forward at all. The hard truth is that most businesses are pretty far behind on the road to continuous delivery. Making a fundamental change to the software delivery process itself is not the same as taking some tools off the shelf as a half-step process.

Software teams need to focus on faster iterations of the software delivery cycle and organize around rapid response to user feedback if the goal is to respond better to customers and users. Although there may be a proxy metric such as the number of releases per month, the best measure of continuous delivery is to track the time from feedback to software updates.

But if you do continuous delivery in a patchwork, you won't achieve your goal.

Source：graph 1

It is easy to see how an organization develops from its current situation to the position it wants to achieve from a gradual perspective. While gradual is always the right way, businesses that are only taking their first steps should not fool themselves into thinking they have come far enough.

Do not rely on the CI / CD tools.

Usually, the implementation of continuous delivery by the team starts with some automated unit tests to automate the construction process. This is a good start, but don't spend too much time focusing on the number of lines of code covered by unit tests. On the contrary, enterprises should focus on verifying core business processes, user transactions, and user interactions to ensure that they still operate in the way expected and required for the effective operation of the business.

The following complex level of the CI / CD strategy is the tendency to pack together with the planned quarterly changes (also a mistake if companies stay at this step). CI became a point of corporate pause efforts. On the other hand, the CD is changed as frequently as possible through pipeline and production. Once an enterprise understands the impact of code changes on users and how they automatically implement them, it takes courage and the money to push them forward.

Source：graph 2

In general, even organizations pursuing CI / CD will have a mindset of seeing change as a risk. This inevitably leads to the belief that changes should be less frequent. This is the opposite of continuous delivery, which hinders companies' full acceptance of CI / CD.

Smaller changes can essentially pose less risk, meaning that high-productivity software organizations should be able to migrate faster. The concept and prospects of continuous delivery depend on the enterprise's ability to deploy small changes continuously. It is necessary to expect frequent releases.

Scope software changes accordingly

Businesses that use traditional ways of thinking (CI tools, unit tests, and acceptance tests) still do not get any real benefits. The scope of changes that an enterprise is deploying should serve as a guideline for the quality issues it can withstand during the software development lifecycle.

Another common problem is that when an organization breaks things down into small changes but still needs to hold a series of meetings, the Change control board or development team must go through strict security checks. Suppose your organization's goal is to accelerate progress by deploying a smaller change stack. In that case, it won't make any progress until it wholly reconsiders its internal formal release cycle approach.

Source：graph 3

Organizations working in strict regulatory authorities such as government agencies must overcome these challenges by making modifications and documentation of their releases. Organizations except government departments can follow their example and overcome document requirements by changing the software and describing how these changes will affect users in the marked-up version. A good example is how the US government's cloud.gov team programmatically generates documents, such as system diagrams.

Enterprises that want to succeed in CI / CD must find a way to incorporate this opinion into some automated test that can be completed quickly, rather than obtaining opinions from anyone on whether the software should be released. Otherwise, every manual step on the road will only further delay delivery

How does the organization solve this problem?

Many enterprises implement CI / CD, but only half of the process has various tools to allow some of these practices. Still, internal processes, checklists, or decisions under administrative authority prevent organizations from posting updates at an average pace.

Many developers are trapped in the traditional software development cycle. They don't even try CI / CD or accept the manual version of CI / CD by focusing on tools, testing, and automation.

Source：graph 4

There are two ways to solve this problem. One way is to use CI / CD Tools first and authorize various development teams to start using standard build services on a company-wide basis. Another way is to identify the development team that benefits most from higher development speed and minor change concentration and allow the experience gained by the development team from this practice to penetrate the whole business.

The latter way works better in most cases because the number of people involved is kept minimum. The more concerned parts of the IT organization about compliance and audit will have more flexibility to understand what happens within a single application. Organizations should be more willing to experiment with individual applications and teams rather than trying to drive the transformation of the entire company.

The objectives of CI / CD are constantly changing, which is deliberately designed. But rest assured that when all teams that can benefit from faster delivery achieve these results, the organization will know that it has begun to achieve the CI / CD.