Some Thoughts on DevOps and DevSecOps

My favourite book on software development is The DevOps Handbook. In my opinion, DevOps is essentially the science of software development. As described in The Handbook DevOps advocates and iterative and experimental approach to software development and operations, which seeks to measurably improve outcomes and reduce waste by correlating specific practical changes to changes the specific metrics (eg. The DORA metrics). While there are specific practices typically associated with DevOps, I think it is more useful to consider it as a science, rather than a rigid structure such as some Agile concepts, or a set of vague principles like those in the Agile Manifesto. Instead, the practices typically associated with DevOps are contingent; they will be adopted and kept for as long as they are provably improving the development process and not one second longer. I regret that my first-hand experience with DevOps practices is limited; my advocacy for DevOps in my previous position was always met with resistance. I am less familiar with DevSecOps as a practice, but I will share what I know. To start, I don’t consider that there is a meaningful distinction in theory between DevOps and DevSecOps. If we consider “DevOps” to be a symbol referring to the scientific approach to software development (which may be controversial) rather than specifically referring to the combination of development and operations teams, and not other teams, then the extension of DevOps to include security considerations in every part of the development lifecycle is natural and inevitable, rather than having it be the specific domain of a security team/expert. If we consider every role and team which is subject to critique and deconstruction as requiring a new name for the movement, then eventually we will have ProductDesignDevSecOps, but I digress. From The Handbook one of the roles of DevOps is to ensure that organizations are increasingly capable of meeting both functional and non-functional requirements, and security certainly is an important example of a non-functional requirement, but not so exceptional as to require a separate conceptual framework.

The practices I find especially useful are: shift-left, the ideal testing pyramid, continuous deployment with trunk-based development, the use of retrospectives to identify pain points and identify priorities for improvement, the use of post-mortem meets to discuss how to eliminate classes of bugs or improve the correction process, the collection of DORA metrics and their use to guide decision making, the promotion of application observability so that we know how our applications are being used and when they are failing. I don’t think I have enough experience to identify overrated practices, though I think all of the above need to be implemented in such a way that they fit the specific conditions of the organization. There are also ways that outdated development culture can creep in and distort otherwise useful practices. This can result in a sort of cargo-cult or ritualistic Agile or DevOps in which specific practices are adopted, without a deep understanding of what makes those practices good in the first place, with the result that their use is limited. I mentioned the practices above as especially useful, not to exclude others, but rather that the mentioned practices are most essential for adopting a scientific approach to software development; they form the basis for experimenting with and evaluating other processes.

I will also point out that some practices which could be considered “overrated” may instead be simply inappropriate for the particular circumstance in which they were applied. Unlike other sciences, for which the physical laws are the same regardless of location, the conditions of software development are different in every company and over time. The optimal practices may be different depending on individuals knowledge and experience, the domain/market for the company, the economic situation, the specific requirements of the product, and the size of the company. So the practices that work for one company may not be applicable to another; this is another reason why a scientific and experimental approach is so important: the practices that work optimally at one point in time may become limiting as the company changes.