During its 10-year history, DevOps has become an iconic term associated with modern software development practice. The software industry invests in related education and ponders whether to even try selling a project without DevOps anymore. The customers either nod for approval or wonder what the whole thing is about. On average, the DevOps could be defined as "A software development model, where the Development and Operations work together in an agile manner in order to accelerate the process and improve quality". But how does one get there, and is it about ideology or technology – both seem to be on sale.
Ideologically, DevOps originates from a traditional compromise made in software development. Whereas the operations teams would like to keep production systems stable and never broken by changes, the development aims at maximum change velocity and avoidance of boring routines such as manual testing. The funding source of course wishes a low price tag for all above. As a compromise, the testing and releasing is performed infrequently, which causes friction between the teams and leads to unexpected situations. This effectively chokes applying the Agile principles, where low lead times are demanded, but technical solutions not necessarily provided.
Fast reaction is a common responsibility
In DevOps, the software development process is built based on continuous change. The principle is best understood with a conveyor belt example: the belts of different departments are interconnected and kept in continuous movement. Persons and machines are performing various tasks on the product throughout its travel on the belt. In case of an error or an unexpected change, all the belts are stopped.
What’s the profit? The teams will gravitate into natural co-operation and solve the problem in order to get the production flowing again. The interruptions become short and massive amounts of unverified changes do not accumulate causing costly disasters anymore. All this essentially requires extending the traditional responsibility area of a developer and applying latest technology to aid this in practice. While the innovation starts to bloom on the first half of the belt, the later phases become uninteresting and overloaded – clear targets of automation.
The pipeworks
Enough with the ideology – the vast majority of DevOps work takes place on the practical level, in implementing a DevOps pipeline consisting of tools and workflows. Automation is naturally expected to result in efficiency, but the actual lifeblood of DevOps is feedback: automatic, fast, solution-oriented and well-targeted feedback. The pipeline development shall be started from the developer end in order to ignite the sense of responsibility and trust in the system. Managed development environment and immediate CI feedback for each change are clear steps to begin with. Later phases include the automation of further testing, release process and the infrastructure administration. A long pipeline leads further away from the developer comfort zone and the cycle may slow down from minute to day level. This applies even higher pressure on the feedback quality and target person identification. Never forget, that even the highest-tech solution is created to serve the people and not itself.
All this does not happen in the blink of an eye, especially on the existing products. Value is added on each step, but in the beginning it mainly relates to quality and predictability, whereas improvements on the efficiency and velocity follow later. As a technology partner, Wapice does not only utilize the best DevOps practices, but also provides its customers with a possibility to stand out strategically with tailored and fine-tuned solutions.
So, is this restricted to the modern web, mobile and service applications? Not really, although the majority of DevOps tools and knowledge truly focus on them. Reason for this is probably their regular ecosystem, standard-like automatic testing frameworks and server environments. The conditions differ substantially for the embedded or close-to-hardware systems and traditional desktop applications. There, the definition of the Ops part might be unclear: as a rule of thumb the DevOps process is considered to end at the last participant able to benefit from the frequent input. It does not need to be the end user - also a separate QA department or the next step in a subcontracting chain are valid endpoints.
Compared to server environments, special hardware restrictions may render the validation phases much slower, and accelerating those to fit into the DevOps cycle requires innovative solutions. The important question is whether or not the stakeholders are ready to make sufficient investment to the validation hardware and the DevOps pipeline development? The sophistication of a software provider is weighed in analyzing a reasonable DevOps scope and frequency and finding or creating the best possible tools for both itself and the customer. I would thus propose correcting the title into the form: “With what kind of DevOps?”.
Original text published in Tekniikka ja Talous partner blog 28.5.