Just when you thought you had all the terminology down, you heard about DevOps and wondered what it is and why your marvelous new startup needs it. At first glance, it’s not even clear whether it’s a person, a team, a set of tools, or a culture. As if that weren’t confusing enough, I’m here to tell you it’s all of the above. So, before we dive into the “how” and the philosophy behind it, let’s first talk about the “why” and the problem DevOps solves.
A bit of history
Before DevOps and all these fancy CI/CD tools, companies typically had two separate teams: Development and Operations (with a wall between them). Developers would write code, zip it up, and email it to Operations with the subject line “Please Deploy ASAP.” Operations usually had no idea this was coming, no clue what they were about to deploy, and no way to prepare. As you can imagine, this caused delays, misunderstandings, and most importantly, production issues.
To solve these problems and meet the demands of a fast-paced, MVP-first, “ship it” environment, the DevOps culture was born and quickly embraced by many startups.
The why
1. Higher customer satisfaction
DevOps reduces the number of production issues by promoting small and frequent releases to production. This ensures the amount of code changes deployed remains minimal, thus reducing the possible number of issues. Combined with automated testing and deployments, DevOps has proven to significantly increase customer satisfaction and retention. It also enables teams to deploy features in minutes, which means customers don’t have to wait for months to see a new feature or bug fix in production.
2. No More "It Works on My Machine" or "It’s a Systems Issue"
The business couldn’t care less about where it works; it’s more about where it doesn’t work. After all, you’re not suggesting we ship your laptop to the customer, right? Or deploy its image to the cloud?
Maybe the issue is caused by a missing system dependency, or it’s a configuration issue. It doesn’t matter, because we now collectively own both the code and the environment. After all, we’re all working towards a common goal: resolving the issue and providing value to customers, no matter by whom or where.
3. Freedom of change
Automated testing and deployments not only increase the quality of your product by reducing manual, error-prone tasks; they also give you the ability to experiment and develop new features or make changes in your code base. With the right tests and processes in place, you don’t have to be afraid of changes or post-deployment issues.
The How
1. Always start with the Why
Start with the problem and make your way to the what and how. Make sure it’s clear that DevOps is a team effort and not just one person’s job. When you begin from the problem, I hope it’s not a real crisis, though having an actual problem (like a production issue) can make it easier to explain things.
DevOps isn’t just something a business or startup needs; it’s a cultural shift that benefits everyone on the team. At the end of the day, I haven’t yet met anyone who wants to get a call at 2 AM to troubleshoot a database issue in production. Hence, it’s crucial for all team members to understand the motivations behind adopting a DevOps culture.
2. Become the DevOps Champion
If you don’t have the resources to hire a dedicated DevOps engineer, start by being the champion yourself. Slowly implement basic processes and policies such as Git branching strategies, QA automation, and automated deployments. After all, creating a DevOps culture is the most important thing; the team can be expanded and specialized later.
Also remember that in agile teams and startups, there shouldn’t really be specialties, only main areas of expertise. As a general rule of thumb, begin by looking at how testing is currently done and start fostering automated testing for QA, as well as writing unit tests for developers. How reliable the application is and how quickly changes can be made (without breaking everything else) are key factors in determining how DevOps is adopted in your startup over the long run.
3. Tailor the right processes
Make sure the process works for you, not the other way around. Every business, team, and application is different, and there isn’t a single approach or process that works everywhere. While it’s very important to look at how other organizations achieve their DevOps goals, it’s even more important to adapt those practices to fit your engineering and business goals. For example, B2C companies adopt DevOps in a very different way than a B2B company serving enterprises.
In my experience, I’ve implemented a blue-green deployment strategy for one application, but used canary releases for another, even though they were developed by the same team. This is why, in DevOps, it’s so important to understand exactly what the application does, how it works, and how customers use it. A flexible, custom-fit implementation will maximize your return on investment in DevOps.
4. Select the right tools
There are many tools and platforms to choose from. The most important thing is that your engineering team is comfortable with them, not just the decision makers or the finance department. After all, your engineers will use these tools heavily every day, possibly for a long time. Another important factor is technology. One platform might be considered the best, but maybe it’s only the best for Linux-based or serverless applications, not for Windows applications. Make sure the choice is made for the right team and technology.
5. Communication and collaboration
In my experience, communication and collaboration have been the most important factors in successful DevOps adoption. To start with, if you don’t have a dedicated DevOps engineer, involve your infrastructure engineers in your standups and make sure they know what changes are being released. This ensures proper preparation before a deployment. If daily meetings aren’t feasible, have them at least weekly or before releases—the sooner the better. This practice fosters a culture of shared ownership and continuous feedback, which are fundamental in DevOps.
6. Monitor Unit Testing and Code Coverage
Writing unit tests is not most developers’ favorite task, primarily because the value isn’t always clear in traditional development environments. Often, we have to sell the idea of unit tests, and the best way to do this is by integrating unit testing into the CI/CD pipelines. Once the tests are written and integrated, code changes can easily be made, tested locally, and then tested again in CI/CD as soon as a pull request is opened.
It is also crucial to monitor unit test coverage by generating coverage reports in CI/CD and setting clear goals to allocate time each sprint for developing and maintaining unit tests. This supports long-term objectives, such as meeting a specific coverage threshold required in certain industries.
7. Get Everyone Onboard
Make sure everyone at the company – especially leadership – understands what DevOps is and why it’s being adopted. This is not an easy task, because you have to understand and communicate both the technical and business benefits. Here are a few tips:
● Speak the Business Language
- Talk about how DevOps accelerates time to market and helps gain a competitive advantage.
- Utilize case studies to show how and why DevOps reduces customer complaints and security issues that could result in loss of revenue.
- Highlight the importance of DevOps in hitting strategic business goals, such as scaling.
● Highlight the Benefits to Engineering
- Emphasize how early detection of issues makes the engineering team’s job easier; fixing issues after release is much harder than fixing them during development or testing.
- Use modern open-source projects to demonstrate how DevOps reduces the amount of manual work and time spent on “deployment babysitting.” It also reduces the time to deploy from hours to minutes, sending everyone home sooner.
- Underscore the benefits of Infrastructure and Configuration as Code, such as spending less time figuring out who manually changed what in an environment and more time actually coding and testing.
8. There will never be the perfect time
Embracing the DevOps mindset when you already have a release out is not easy: people are used to doing things a certain way, and changing that can be challenging. But the sooner, the better.
You might be thinking, “This is all great, but we have other priorities now, like releasing the product or a new version.” This is where you need to think about the marathon, not the sprint. I doubt you want to risk shipping production issues and damaging your product’s reputation.
Waiting for the perfect time to start can take forever and could lead to more production issues and reputational damage down the road. The cost of implementing DevOps grows higher and higher as your team and product mature. The bottom line is that now is always the perfect time.