Continuous delivery and early feedback

Posted in systems-engineering with tags production operational-overhead continuous-delivery systems-thinking - Wednesday, August 1, 2018

Businesses require and expect rapid feedback from their software engineering projects. This enables the business to engage in early evaluation of its choices, so as to ensure commitment to its strategies, or to correct course if need be.

Ensuring continuous and meaningful early feedback in software projects, can, however, be a challenge. There are many opinions and many viable technical mechanisms that can be brought to bear on the problem. However, there is a risk in investing energy in the problem and not seeing suitable returns.

When working with teams I find that it is important to introduce the explicit notion of experiments. The concept of an experiment provides the necessary unifying thread that helps to underpin, and focus, the many choices and refinements that the team will need to make in order to achieve continuous delivery and early feedback.

Experiment: A scientific procedure undertaken to make a discovery, test a hypothesis, or demonstrate a known fact. ¹

Following this, and guided by systems-thinking, I introduce the view that we are actually continuously running experiments at multiple scales in the organisation:

software engineers need to test the correctness of implementations, or the performance characteristics of specific algorithms and data structures.
designers need to test their assumptions about user interactions and preferences.
process engineers need to test the connections in data flows between subsystems, third-parties and humans.
architects need to test their choices regarding system structuring and decomposition.
business owners need to evaluate their efforts against market sentiment and adoption forecasts.

In light of these varying scales of experimentation, the value derived from the work of engaging in efforts to achieve continuous delivery and early feedback, is dependent on meeting the needs of all of the stakeholders while still making use of the available technologies.

Below I touch on some additional details regarding the aspects that can be brought together in order to make continuous deliver and early feedback work for the organisation. That is, both improving the environment for software engineering teams and providing businesses with the crucial feedback that they need in order to gain a competitive advantage.

more...

Patterns and Tooling

In order to fully close the loop on running useful experiments within your organisation and deriving value from the process, you need to cover the full development process. In this context, we can take a slightly narrower view and consider:

Continuous delivery of software to production.
Monitoring of software running in production.
Alerting on deviations from SLAs for running software.

As the industry has started to embrace a greater degree of automation around the process of development software, and evaluating the results of these experiments, a number of platforms have been developed to support the various stages of automation.

For CI/CD we have off-the-shelf tools such as:

GitLab with CI/CD support.
Jenkins with Pipelines to support CI/CD.
Travis CI supporting CI/CD for GitHub projects.

While for gathering telemetry and monitoring systems we have tools such as:

StatsD for aggregating telemetry emitted from software.
CollectD for collecting and collating a broad range system telemetry.
Graphite for collecting, collating and graphing telemetry.
Graphana for collecting telemetry and building dashboards.
Prometheus for collecting telemetry and defining alerting rules.

The actual choice of the tooling for a specific organisation or software engineering team depends both on the existing context and the problems being addressed.

When approaching the problem of continuous delivery, I work with software engineering teams to ensure, that the complete software development life-cycle will benefit from these investments; that the rapid delivery of software to production is counter-pointed against the collection of meaningful data from production; that all disciplines supporting a software engineering effort can benefit from the rapid release cycle; and that the rate of change to production systems is aligned with the business needs for agility and early feedback.

Continuous delivery and early feedback are cross-cutting concerns that, as with any other system design, need to be aligned with the expectations and needs of the business.

By building this alignment into the development processes and sharing the common principles of directed experimentation, it is possible to see high quality software systems being engineered that deliver value to the business.