Happy Miles of The DevOps Transformation Journey
Even though the very term “DevOps” is known since 2009 thanks to IT guru Patrick Debois, hardly anyone can clearly define the phenomenon once and forever. DevOps is neither a process nor a technology. Many prefer calling DevOps a specific culture. Just within such a culture the DevOps transformation process is possible and makes sense.
While conceptual definitions of DevOps remain a matter of opinion, practical approaches to DevOps transformation can be considered quite universal. We are going to share our expertise in critical steps making a successful DevOps transformation strategy easily implementable.
Why has DevOps emerged?
It is worth begging with what we mean when saying “DevOps”. As we believe, DevOps reflect the relationships between software developers and those who test and operate what the developers create. In the relationship framework, a specific way of thinking is used to shorten the software development life cycle due to faster feedback. As a result, the delivery of features, updates, and improvements appear more frequently.
DevOps transformation has emerged not from scratch. Two main groups of far-sighted IT experts were saturating the origin of DevOps with their practices:
- Sysadmins. They have brought some key recommendations inherent in ESM (enterprise system management) regarding hardware operation. Those were configuration management and system monitoring, inter alia;
- Agile devs. They have transferred Agile development principles into the delivery and services.
The core problem laying in the outbreak of DevOps practices was the tough choice that software companies’ owners had to make. On the one hand, users were demanding new features, services, and income streams to appear as soon as possible. On the other hand, the same users were expecting stable systems without bugs and failures. As isolated outcomes, the desires were mutually exclusive.
The DevOps process has appeared to solve the dilemma, therefore. The way of doing so is to integrate everyone involved in both the creation and operation of software: devs, QA engineers, security specs, sysadmins, etc. Their missions should be combined into a highly automated workflow running towards a common goal: fast delivery of high-quality software that meets all user expectations while keeping the integrity and stability of the whole system.
How to adopt the DevOps culture
What makes desperate groups of IT specs coordinate their efforts? They have to share a set of basic DevOps transformation principles going far beyond traditional disciplines and roles. They may include, for instance:
- Determining common expectations and priorities that drive the entire team forward;
- Establishing collaboration as within groups as at an inter-group level;
- Automating recurrent processes to save time for higher-level works;
- Making feedback an integral element of a working process by measuring everything that has been done;
- Sharing data with everyone involved to strengthen the culture of collaboration by using new competencies.
Despite no one-size-fits-all DevOps transformation paradigm is available, the famous CALMS acronym can express what the majority of DevOps specs consider the main pillars of DevOps transformation:
- Culture: the way of thinking that provides intra-company collaboration;
- Automation: opportunities to eliminate redundant manual labor;
- Lean: detection of losses of time and resources by means of visualization of value stream pipelines;
- Measurement: critical data must be continuously measured;
- Sharing: either Kanban or another visualization method is used to let everyone realize how the entire process runs.
To follow each of the above-mentioned principles in practice, certain tools are worth applying to various DevOps processes. The tools are grouped according to capabilities and tasks inherent in DevOps-enabled workflows.
Tools and techs for DevOps transformation
DevOps transformation blurs the borders between stages of the software development life cycle. The software starts appearing in a different way with DevOps. The entire process goes through specific stages each of which is covered with special tools and techs. To expect DevOps transformation to go smoothly, an organization should have specs with sufficient skills in such techs. But first of all, it is necessary to understand to which DevOps processes those tools and techs can contribute.
This is the core of success in DevOps transformation. In addition to devs and admins, all the other teammates such as QA engineers, cybersecurity specs, project managers, and even business owners should strive to achieve tight intra-company collaboration. The following are some examples of tools to create a common working environment:
- Clouds: AWS, Google Cloud, Azure, OpenStack;
- Data centers: Rackspace, Unicept;
- Security: Suricata, Ossec, Application Gateway, etc.
DevOps is based on various toolkits for automated end-to-end software development and product delivery. They are so amazing that many consider DevOps as just a set of tools. Such a view is hardly correct since DevOps transformation is primarily a culture, a specific shared vision that encourages teammates to use one or another tech for automation.
Automation and orchestration techs are numerous: Kubernetes, Docker Swarm, Ansible, Python, Bash to name a few.
Some specs suppose that continuous integration (CI) is the very cornerstone of DevOps. The method has been invented by Grady Booch while the term as such is widely known in Agile development. CI goes against the image of a “genius lonely coder” who weeks and months can spend over a particular module before other programmers can see the result.
Continuous delivery (CD) is a practice that allows developers to have a build ready for release at any moment. Highly productive DevOps experts usually make several deliveries a day. Source code management (SCM) systems and data management ones can be included in the CI/CD group of techs as well.
One of the leading tools in this category is GitLab-CI that provides continuous integration directly in your repository. The other popular ones are GitHub, Jenkins, and BitBucket. Data management tools include FlywayDB, LiquiBase, and Flocker.
Continuous testing (CT)
CT helps build a decision-making system that evaluates risks brought by each application to your company. It makes developers meet customer expectations while enabling project managers to make sound decisions. The feasibility of CT is worth the investment since the high quality of releases is never a waste of time and effort.
Some categories of tests do not fall under CT inherent in DevOps. The so-called unit tests and component tests are usually conducted by developers only. CT belongs to integration tests and walk-through tests mostly. CT can be measured and assessed with such metrics as DLT (Deployment Lead Time), MTTR (Mean Time To Repair), and MTTD (Mean Time To Detect).
One of the best testing frameworks in this domain is Cucumber created under the BDD (behavior-driven development) paradigm.
Continuous Monitoring (CM)
Despite continuous testing, errors happen due to continuous delivery. Unfortunately, there is no way to exclude mistakes completely. Continuous monitoring is aimed at detecting errors in real-time. Besides, CM helps figure out the causes of mistakes as well as proactively prevent failures.
The typical DevOps tools for continuous monitoring include Grafana, Prometheus, ElasticSearch, Zabbix.
Steps to harness the DevOps transformation process
Almost all DevOps engineers agree that people, tools, and processes are the main elements in building a viable DevOps culture at any organization. Hence, the steps necessary to make along the DevOps transformation journey have to be considered through the lens of those elements.
Step 1: Audit and planning
Before implementing any DevOps practice, it is worth figuring out how well a company is prepared for the process. No other approach but a thorough audit of both the company’s infrastructure and labor resources can help. Hence, the first step of DevOps transformation implies the evaluation of the current state of affairs at the company in terms of planning the measures necessary to make while introducing DevOps practices to staff.
The availability of various automation tools can tell about the level of DevOps expertise the whole team (or just a fraction of it) already possesses. Besides, it is necessary to assess the extent of intra-company collaboration taking place over the entire software development life cycle. And finally, the very awareness of staff regarding the desired DevOps transformation should be clarified. This is about understanding the reasons to begin the DevOps transformation journey as well as how such a motivation can be strengthened if necessary.
Step 2: DevOps coordination center
Even though the performed audit can reveal quite a clear inclination of the company towards DevOps transformation, allowing the process to go spontaneously is hardly a good idea. It is worth establishing a dedicated internal entity to coordinate all DevOps practices. Such a core structure should accumulate all DevOps competencies to share the knowledge across the company.
The DevOps coordination center helps the team retain a continuous focus on the most appropriate tools, techs, and approaches capable of improving the general DevOps culture.
Step 3: Indicators and metrics
No progress can be detected without predetermined metrics and indicators that can be measured and assessed. Create a list of key performance indicators that should deliver clear signals of how well your DevOps transformation strategy works. The variety of such metrics and indicators depends on what the team considers critical to track.
Deliveries per day, unplanned work rate, forced reiterations, and other process-specific metrics can fit along with the widely accepted ones such as Deployment Lead Time, MTTR, and the like. Collecting the metrics should be arranged by specially assigned teammates whose roles and responsibilities should be recognized by the other staff beyond any doubt.
Step 4: Feedback and communication
The success of your DevOps transformation strategy directly depends on how actively teams, groups, and individuals communicate throughout the entire software development life cycle. The ability to collect necessary feedback in due time should be prioritized as one of the most critical soft skills. No useful action can happen without a meaningful reaction in DevOps.
All indicators and metrics can contribute to your DevOps transformation only if everyone involved in the process regularly reflects on the causes and consequences of the collected data.
Step 5: Trial projects
Expecting a new DevOps pipeline running like clockwork is hardly a wise approach without specially arranged trial projects. The development process selected for a trial project should be taken as a model SDLC for the upcoming DevOps pipelines. Select new tools, approaches, and methods to give the “new wheels” a run. Perform such a test drive to collect as many metrics and feedbacks as possible to analyze. The results can suggest how well your new DevOps pipeline is ready for scaling up at the enterprise level.
Step 6: Scale-up
This is a moment of clarity when you decide to transfer the DevOps experience gained from trial projects into corporate day-to-day routines. To tell the truth, this is just the beginning of your journey since DevOps transformation is never static. Your subsequent DevOps pipelines will evolve as far as your teammates are continuously cutting their teeth on. Keep tracking whatever is possible along the way while introducing new improvements into your DevOps transformation strategy.
Mistakes on the way to DevOps transformation
Sometimes, top management tends to forget about the final business objectives while introducing DevOps practices into the development process. DevOps transformation as a thing-in-itself instead of the delivery of software products begins dominating. Developers are getting caught up in endless updates and releases that bring no value to customers.
Try to avoid the following typical mistakes arising when DevOps transformation is implemented too straightforwardly:
- Always use an integrated runtime that works on desktops, servers, embedded devices, in a cloud, elsewhere. It significantly simplifies accomplishments in security, QA, and deployment. The “but it was running well on my computer” cop-out should leave your thesaurus forever;
- Never use Scrum for micromanagement. Daily Scrum sprints should last 15 minutes max. If longer, something goes wrong. If sprint reviews do not result in positive changes, Scrum is meaningless. Hold off on Scrum if the only objective is to keep a team under pressure;
- Avoid optimistic scenarios when conducting continuous testing of your apps. Remember that real-life operation includes unpredictable user behavior and discarded data;
- Avoid excessive testing since this is a double-edged sword for the DevOps transformation process. A lot depends on a certain product you develop and the failure rate determined for the product. Maintaining a proper balance between continuous testing and other DevOps processes is important;
- Do not practice DevOps without Agile development. Agile provides interactions between customers and developers to improve the quality of finished products. If there is no such goal, what’s the point of implementing DevOps then?
The DevOps transformation journey always has a beginning which is more than can be said for its end. People, tools, and processes lie in the background of everything happening in DevOps. Automation and communication are the two pillars upon which the DevOps culture is built.
The DevOps transformation strategy includes a sequence of activities to be implemented one by one to let new DevOps pipelines appear. All the steps on the way to DevOps transformation are graspable enough to get them right. The most important thing is having a strong intention.
Contact us today if DevOps transformation is close to how you see up-to-date software development. Strong DevOps competencies along with an individual approach are guaranteed.