The DevOps model brings developers and administrators closer together and enables agile methods in both areas.
In the first article of my “Time to Production” series, I highlighted best practices for optimizing the time it takes for a new feature from a product owner’s request to the completion of development. With the completion of software development, however, the feature is not yet available to users in the production system. The idea of also speeding up the second part of the supply chain after a change has been handed over to the operator – without any compromise in availability, security or other quality features – is obvious. Here too, the application of agile principles is promising. DevOps – the composition of the terms development and operations – is a model and not a role. It is neither meant that developers take over the task of operators and administrators, nor vice versa. Content of the DevOps model is the interdepartmental cooperation between development, quality assurance and operation as well as the implementation of best practices in software development in the field of service management and system administration.
Series of articles “Time to Production”:
- How much agility is good for software development?
- DevOps – agility in systems operation
- DevSecOps – the deployment pipeline for secure software (soon on this blog)
Cross-area collaboration instead of accusations
In commercial software development, we have learned that the duties of a customer or product manager do not only consist of placing an order and signing the acceptance declaration. The technical and business complexity on the one hand and the time pressure on the other hand require frequent prompt interactions in order to control supplies of information and infrastructure and to manage necessary changes. Development and operation are not silos either. They have to agree very early on the log and protocol outputs of the application that are to be automatically checked in the production environment. The same applies to interfaces between the application and monitoring systems, so that they can monitor whether critical components are still “alive”, and to the configuration of the system environment and its external interfaces. Quality assurance must use the same versions and configurations of the infrastructure components in its tests as in the production environment. System operation and product managers need to agree on the expected development of the system load, security requirements, etc. The quality assurance department must also ensure that the system is operated in the same way as in the production environment.
Infrastructure as code
To be able to react quickly and flexibly to changes in system environments , system administrators must proceed in a similar way to software developers. Scripts should be available for all administrative tasks, and configurations of servers or virtual machines, for example, should be stored in files. Both belong under the care of a central version control system, with which changes are traceable and reversible. Before using them, new versions of the scripts and configurations should be tested so that the tests cover all use cases and are also traceable.
Tools reduce the workload
Today, there are numerous tools for system monitoring and configuration that simplify the work of system administrators. To support the administration and configuration management of complex system environments, PASS has developed its own tool, the so-called PASS Application Cluster Manager (P.A.C.Man). With this tool, the execution of all scripts in a system can be planned centrally or triggered manually, taking into account their dependencies and relevant states. Compared to the manual handling of the scripts, this tool reduces the effort significantly in addition it requires less expert knowledge for the administration and avoids errors.
Virtualization minimizes risks
Tools such as Vagrant and Docker can reduce the risk of discrepancies between test and production system environments. The production environment runs entirely on a virtual machine, including the operating system and all system components. The new release is deployed on such a virtual machine and after quality assurance; the virtual machine is completely transported into the production environment as a container. Virtualization enables the development process to directly access the production environment – its virtual image.
Continuous delivery through automation
The build process from the code repository can be automated using appropriate tools. Tool-based code analyses can be triggered according to defined sets of rules and the further use of the build can be made dependent on the number and severity of the rule violations. Unit tests, integration and stress tests as well as GUI-based functional tests can also be automated with appropriate tools. In addition, there is the automated distribution of the components in the system landscape. All these steps together result in a deployment pipeline with which any code checked into the repository by the developer could run automatically over several quality assurance levels into the production environment.
In purely technical terms, this would enable us to reduce the time to production to a process runtime that we would perceive as real time. Depending on the availability requirements and the associated time windows for the introduction of new releases as well as aspects of product management, the decision for a go-live is usually not left to the developer. At the end of the pipeline, it makes sense to install a production-related test system or an appropriate container as a stopover and basis for decision-making. The automated transfer into the production environment is then carried out by the human decision maker at the push of a button.
The DevOps model means no more and no less than a consistent use of tools and increasing automation in the area of systems operation – accompanied by close cooperation between administrators, development, QA and product managers. Agile software development and DevOps are the instruments to noticeably reduce the time to production. But where is the security? This is the subject of the third article in this series: “DevSecOps – the deployment pipeline for secure software”.
How pronounced is the DevOps model in your IT development and system landscape?