Automation

Automation plays a key role in the development of a product. Nightly builds and tests are automated and verify the integrity of the product. Operations uses scripts to automate product deployment to production. And developers use scripts to help them automate and deploy their code into their own personal workspace.

Automation can have a significant effect upon product quality. Take for example – nightly builds.

As it stands, most nightly builds run unit tests and the results of the build and tests are published in a report. And this report indicates the status of the build as well as the results of unit tests run by the CI/CD pipeline. Users can then read the reports and determine if the build failed and / or which unit tests passed or failed and why. This process is extremely useful as it ensures that your product actually builds and runs successfully.

However, the tests that are being run are unit tests which, good as they are, do not actually tell you the running state of your system as a whole. A user story which has functionality in the UI, in the service and in the database may run a unit test for each part of the user story successfully. But when all the parts of the user story are deployed into an integrated environment, they may not work at all or only work partially. The question arises, are the nightly builds – good as they are – providing the organization a view of how the product actually works?

Product Visibility

The question about nightly builds also brings up another question: Where does the product actually live in an organization? It may seem surprising  but for most organizations, the product as a whole, is visible only for a short while in integration test and then finally in production. In the case of integration testing, the product is visible only to the developers and the testers and to no one else. The only place where the product can be shared fully is when it is live in production.

Besides these two areas, the other places where the product code can be found as a whole is in Git. However, the product that lives in Git is in a state of suspended animation. It is not running and can only be experienced when developers build and run it on their machines or elsewhere. The rest of the time the product is in various states of development and is distributed throughout the organization. It is on developers machines, system tests, ops, or wherever someone pulled the code from Git. By and large then, for most organizations, there is no single instance of a running product accessible to all members of that organization.

Over-Managed Processes

Perhaps the relative invisibility of a product, as it is being developed, is a determining factor for over-managed software development lifecycles. Not being able to see and experience your product gives rise to a sense of uncertainty as to its progress, its capabilities or its quality. The effort to track and manage software is a function of the uncertainty surrounding software development. And so there are tools, quantitative metrics, code reviews and automation to reduce the risk of developing software based products.

The result of this focus on the process results in the over-management of software development. It also loses focus on the larger picture of the product being developed.

In other words organizations stop seeing the forest for the trees.

Internal Releases

Besides automation’s application for nightly builds and its use in teams developing software, the organization itself can use automation to provision an on-premise cloud from the artifacts of a nightly build. This capability would create an organizational pipeline responding to events in the nightly builds to stand up an instance of the cloud with the latest working version of the product. This working version then becomes available to all members of the organization. It is the blessed version of the product that can be shared with everyone within the organization.

The immediate effect of this is to reduce the uncertainty surrounding software development, but it has other benefits as well:  It makes everyone in the organization part of the same team and promotes a shared responsibility for product development. But it goes further than that. The version that is accepted by the organization can then be used by operations to launch the code into production.

Internal Releases

Besides automation’s application for nightly builds and its use in teams developing software, the organization itself can use automation to provision an on-premise cloud from the artifacts of a nightly build. This capability would create an organizational pipeline responding to events in the nightly builds to stand up an instance of the cloud with the latest working version of the product. This working version then becomes available to all members of the organization. It is the blessed version of the product that can be shared with everyone within the organization.

The immediate effect of this is to reduce the uncertainty surrounding software development, but it has other benefits as well:  It makes everyone in the organization part of the same team and promotes a shared responsibility for product development. But it goes further than that. The version that is accepted by the organization can then be used by operations to launch the code into production.

Summary

By using automation with an on premise cloud, the need for over-managing the software development lifecycle should be mitigated and the shackles imposed on developers can be removed. This can release the potential energy that is latent in an organization and which current managerial practices suppress. Once these inefficiencies surrounding the SDLC are removed and the latent energy within the organization is released, the kinetic velocity of product development increases and a higher quality product can be pushed to production in a shorter period of time.

Ideate Iterate Innovate