Kiva kun löysit tämän artikkelin! Se sisältää varmasti hyvää tietoa, mutta pidäthän mielessä, että se on kirjoitettu 7 vuotta sitten.
We’ve been blogging about DevOps earlier. We’ve done tons of DevOps projects. Still, it seems that the big DO-wave has just started to rise. This blog reflects from the ideas of the doctoral thesis by Marko Leppänen: Vanishing Point: Where Infrastructures, Architectures, and Processes of Software Engineering Meet and its references. If you feel that you need more than what this blog has to offer, then it is time to get serious and learn from the awesome thesis of Dr Leppänen. Picture 1: Artistic impression of the DevOps wave gaining momentum
Fast, cheap and realiable!
We all know the holy triangle of software project management. A certain scope of features delivered in a certain time produces a certain cost. Fast release means less features. While business needs to follow a fast changing business environment, long delivery times are unacceptable.
Need for speed has produced Agile methods
In Agile, small feature increments deliver constant value stream in a form of new software features. Small increments ensure a continuous value stream, enable a rapid feedback and create a tighter co-operation with the customer. A dream come true. Picture 2: The holy trinity of project management. You may visually think that the triangle must stay equilateral or you loose quality. ”Cost” may be also tought more generally as resources. And ”Requirements” as value produced.
Continuous Deployment
Continuous Deployment minimizes the overhead related to software integration, testing and installation. While it becomes possible to add and remove features easily from the live product, it enables the real end-users to experimentally define the real value of the features. Fast release cycle requires adequate maturity level of DevOps. The maturity level is defined by the overall execution of Process, Infrastructure and Architecture.
OK, sounds like a plan. I wanna be continuously agile. How hard can it be?
Speed is pronounced P-A-I
For the rapid increments to work, all the additional overhead needs to be minimized. In other words, everything must be automated. That means tons of tools. The software architecture itself must support incremental releasing. So, you need a modular architecture. In other words, Continous Deployment requires a combination of process, architecture and infrastructure decisions.
Picture 3: Can you find the sweet spot of DevOps from the picture with three bubbles?
Process
Process can mean anything. Here it means people and ways-of-working. You need the people with the right skills and the right mindset. And you need to empower them. When you have the right people, the process acts as a catalyst or blocker. In other words, you need ability from people and Kaizen from processes.
I’ve divided the Process into sub-chapters titled Culture, Testing, Decisions, Crossfit and Measure. Before going into those, let me draw you a pie diagram about it. OK, let’s make it two. Picture 4: People pie lists the ingredients of personal ability. Process pie describes the Kaizen style continuous improvement. You need both, but start with people. If you’re gonna have only one pie, please make at least sure to make a double crust apple pie.
Culture
Organization ensures that someone has knowledge and authority to take care of all the functional areas of the software development. Stuff like requirements and bug tracking, development, testing, deployment and quality assurance.
There will be cross-functional roles and independent roles. For example, architect versus quality manager, as well as developer versus tester should be independent to avoid bias. Similarly, operations requires different mindset compared to development. You don’t need much of old school organization structures, but clear roles and mandate to act.
A situation where people do not have opportunity to coordinate, collaborate, or cooperate their work is called social debt. It is a parallel for technical debt at the organizational level
Testing
In agile world tests are often developed even before the actual functionality. Integration and testing is being executed automatically, triggered by push to version control. This requires some infrastructure and tooling. But first of all it requires the right mindset. You need to include testing into development.
High speed of development is not enough alone, as the development also has to have a direction and quality
Decisions
Decentralized decision making enables timely and effective decisions. This is a form of minimum viable management, where the decisions are made based on collective intelligence. In the knowledge work there is often a need for timely decisions on complex subjects. In such environment, the only timely and precise decision method is based on collective intelligence.
In the complex domain there are no right answers. Therefore, one needs a safe-fail environment
Crossfit
Cross-functional people enables flexible resourcing and fast decision making. Individuals are able to support each other on their assignments. ”Anyone” can take over anyone else. This kills hierarchies and siloes, enabling wider scope of information, decentralized decision making and transparent ways-of-working. Cross-functional consists of both skills and attitude. Attitude first, skills will follow.
”Social developer” is an overarching concept, where tools, methods, and processes must be in line with each other
Measure
Metrics are collected automatically by the infrastructure. Metrics are used as a base for decision making. Metrics force continuous improvement. Metrics enable fast and timely decisions. In DevOps world the production environment metrics describe the value of existing and newly deployed features.
Increased situational awareness caused by the quick feedback improves developer motivation
Infrastructure
The nature of the tools used for development, testing and deployment depends widely on the domain, technology stack, legacy and user preferences. Still, a continuous deployment pipeline from coding to deployment is required. Process and infra are interrelated, while infra is used as means to automate and speed up the processes. As you know, culture beats strategy. So, for example a cloud strategy is useless if the people disagree.
Infrastructure and process are interrelated
Architecture
Architecture depends on the chosen tools and technologies. I’ve divided Architecture into sub-chapters Modular and Deployment. There is a reason I’ve taken the Deployment (infrastructure) chapter under Architecture. Keep calm and read on.
Modular
Code produces the functionality of the system. Architecture acts as an enabler for the non-functional requirements. Combination of these two can be thought to represent software quality. ISO classification for software quality follows functionality, reliability, usability, efficiency, maintainability and portability. Inside-outside division of the quality means that quick-and-dirty implementation of an external feature creates technical debt inside the code. Technical debt slows the future development. On the other hand, debt can be seen as a resource, which helps to cash in valuable features faster. However, payback is inevitable. Most common form of payback refactoring. Automated tests are the only way to ensure that the payback flows the right direction.
Technical debt leads to inaccurate time estimates and speed makes the technical debt visible
Deployment
Technology selection is an architectural decision. There is a clear connection between the selected architecture and ability for fast deployment. The power of agile comes from small incremental and iterative updates. A live installation is a sign of the done requirement. In Lean terminology all the non-live code can be seen as inventory and waste. After the continuous integration works, the next logical step is continuous deployment. Operations isn’t a separate of Development but a logical continuum. Here comes the big ideological step to treat the environment as a part of code. In DevOps development quality assurance and operations form a holistic approach.
Here’s a cool old-school picture presenting the logic of DevOps. Yes, it’s old school while only the PO is having a beard.
Picture 5: DevOps big picture.
Continuous * (everything)
Continuous * provides numerous benefits. Fast delivery feels good at the both ends. Quick feedback increases situational awareness. Flow and visibility increases the developer and stakeholder motivation. Continuous * focuses the communication on what matters most. End users are measured on real-time, so there’s no need for error reporting. Developers can just commit, no need to inform anyone. Automation takes care of the process. Business owners dare to try new ideas, while proof-of-concept implementations are fast to deploy and self-evident to measure. Failing is fast and safe. Everybody are Lean and beautiful.
Five cents
Remember PAI. Process, architecture and infrastructure are interrelated.
1. Have a well-automated deployment pipeline that is fast to setup
2. Have identical production and development environments (that are fast to setup)
3. Use fast communication and feedback channels
4. Be Lean
5. Don’t use the domain as an excuse. Speed is a state of mind
