High-speed innovation allowed companies like Amazon, Google, and Netflix to dominate markets. Yet at some point, they all faced issues familiar to established companies. Slow, risky releases and a rift between development (dev) and operations (ops) pushed them to adopt a radical DevOps strategy.
Before the advent of DevOps, companies had separate “walled-off” teams of developers, testers, and operations.
All too often they had conflicting goals and little insight into other “camps”.
Developers would spend 3-4 months building a ton of features and then try to merge their code. This process was slow and tended to produce lots of errors.
After a looooong integration, devs would hand their code to QA.
When testers discovered a ton of bugs, developers would often respond with the classic,
Source: TeePublic
Once finger pointing is over and bugs are worked out, developers would pass the torch to operations.
Ops would then try to deploy the code to production. If deployment failed, they’d blame devs for providing faulty artifacts.
As working software was none of developers’ business, Ops would have to swallow their pride, stock up on coffee, and fix the mess.
Throwing issues over the wall to another team creates bottlenecks that slow innovation. In the world of Agile development and SaaS products, this can destroy your competitiveness.
The impact DevOps strategy can have on a product team
DevOps emerged as a response to these issues.
It’s a culture that aims to bridge different teams and eliminate communication bottlenecks. DevOps relies on standardization of environments and extensive automation throughout the development pipeline.
DevOps helps organizations to:
- Deploy more often (and with a higher success rate);
- Fix defects earlier and faster;
- Improve product quality;
- Reduce time-to-market;
- Better adapt to market needs;
- Boost user satisfaction;
- Increase productivity; and
- Improve teamwork.
But what about the actual DevOps implementation strategy that empowers such high-performing IT teams?
Step 1: Assess your current state and understand DevOps processes
One of the main reasons why companies fail to realize DevOps benefits is through lack of planning.
Before you automate your development pipeline, take a look at the products you’re building:
- What are their hardware/software requirements?
- Are they storage-intensive or processor-intensive?
- What are their non-functional requirements (e.g. performance, security, monitoring, etc.)
At this point, it’s important to keep in mind that your DevOps transformation shouldn’t address issues of one particular product. So focus on a cloud-based framework that fits most of your solutions.
A DevOps implementation plan will include abandoning some of your old methods to gradually adopt new practices:
- Separation of environments into development/test/staging/prod is the first requirement for DevOps transformation. Setting up environments manually takes a lot of time and requires attention from the ops team.
- Agile development is another prerequisite. Focusing on rapid delivery and small cross-functional teams requires more environments. The only way to stay agile is to increase automation and move past the ‘silo’ culture.
- Microservices architecture is an approach to building cloud-based software that consists of a large number of independent services. Each service represents a single feature and communicates with other services via APIs. Backed by small teams with a strong sense of ownership, services can increase the speed of innovation and make apps more flexible. However, the increased number of releases requires more automation.
- Automated regression testing checks that updates to the code don’t break existing features. Ideally, regression testing should be fully automated so that QA could focus on new functionality.
- Continuous integration (CI) is one of the first steps in a DevOps strategy. CI allows developers to automatically build, test, and integrate new code into a common repository. Version control helps to resolve merge conflicts. This saves a lot of time and allows multiple devs to collaborate on a single project.
- Continuous delivery (CD) builds upon CI allowing you to deploy code to staging/production environment with little to no manual intervention. Releasing as often as possible simplifies troubleshooting.
- Continuous deployment goes one step forward and automates the deployment process. The only time you need to intervene is when the new code fails tests. This allows companies like Amazon to make hundreds of mini-releases a day. The new code can be made available to select groups of users. Automatically collected feedback helps companies respond to customer requests in close to real time.
Continuous Integration vs. Continuous Delivery/Deployment
Step 2: Choose your DevOps toolchain
There is no “one-size-fits-all” approach when it comes to DevOps.
For each step in the DevOps toolchain, there are dozens of options. The key to selecting the best DevOps tools is knowing your requirements and having the courage to experiment.
So consider:
- Your requirements and tech stack;
- The choice of cloud provider; and
- Your expertise.
In case you have a multi-cloud setup, you’ll have to choose the tools that work with all providers.
These tools should also support the IT/network resources needed to manage connections between your microservices. The tools should be connected to the cloud provider’s monitoring, security and governance features.
If you rely on private cloud services, you’ll need an interface to your cloud provider’s management system.
It took us some time to find a set of tools that works for most of our projects.
MindK DevOps tool package
There is, of course, no “perfect” DevOps stack. Each company will have to experiment and choose the tools that suit their needs and resources.
Step 3: Test early and focus on automation
Finding bugs earlier in development saves a ton of time and money.
Test automation is one of the cornerstones of successful DevOps transformation. It cuts the amount of routine work required to test newly deployed code and frees hands for in-depth exploration testing.
In the context of DevOps and continuous delivery, test automation allows:
- Running a series of unit/integration/regression tests each time developers commit a change to the code. This allows you to quickly discover bugs and make sure new changes don’t break the system.
- Checking security, governance, monitoring and other related services.
- Generating large amounts of realistic data for further manual testing.
As all tests can’t be automated, it makes sense to begin with cases that are laborious, repetitive, or critical to your business.
Most companies simply automate functional tests. This produces scripts that are hard to maintain. A better approach is to start bottom-up, with Unit tests. Written by developers, they check the smallest units of code with great speed.
A bug discovered at this stage can be fixed at 1/4th of price compared to post-release.
Your next target for automation should be API tests that can check business logic before the app’s UI is ready.
The final challenge is maintaining your automation scripts. There are a number of practices that can make your tests more resilient like behavior-driven development, UI-independent scripts, and page-object patterns.
Read more: how to automate your tests and make them maintainable.
Implementing the DevOps transformation for a leading reputation management company in the US [explore the case study]
Step 4: Remove organizational barriers
DevOps isn’t only about technologies and automation.
As startups grow into established businesses, they become resistant to change. The existing workflows and habits, both among executives and employees, can become the main barrier to adopting DevOps practices.
Your efforts will fall short without full support from company executives.
Your path to transformation will depend on the types of products you’re building, the tech you use, your internal structure and processes, etc.
You’ll have to experiment a lot, which is impossible without a culture that encourages learning from failure.
An organization that fears mistakes retards growth.
That’s why some companies reward developers for disclosing mistakes that can help improve efficiency.
You can start with project retrospectives where teams discuss what went wrong during the development. The key is to assign no blame, but learn from each other and discuss what can be done to avoid similar problems.
Regular retrospectives help build trust and understanding between team members.
Once you have support from executives, you’ll have to involve rank-and-file employees in breaking the silos.
Software that runs in production should become everyone’s goal.
With the transformation in DevOps roles, you’ll have to assess the skills they lack and invest into training.
At the very minimum, developers should understand clouds and environments.
Ops, in turn, should learn to think like coders (e.g. infrastructure as a code, health monitoring, DevOps pipeline automation, etc.).
Source: plutora.com
They should start working on projects earlier and continue helping throughout software development lifecycle. Instead of solving developer problems manually, they’ll assist in setting up environments, testing code and deploying it to production via APIs and self-service platforms.
Step 5: Build your DevOps MVP
The scale of change can be overwhelming, so it’s better to approach it in manageable chunks.
Start with main pain points and identify where DevOps practices can bring the most benefits.
- If major issues happen at the coding/build stage – start with CI/version control.
- If you suffer from poor test coverage – invest in test automation.
- If the pain comes from infrastructure and deployment – continuous delivery is the way to go.
You’ll have to try new tools one by one, starting with the development side then gradually move towards production and integration with your cloud platform. DevOps outsourcing can be of great help at this stage by giving you the access to resources you might lack locally.
When enough time has passed for your team to learn DevOps workflows, you can make another assessment to find new pain points.
Along the way, you might encounter some major possible setbacks:
- Cloud costs that get out of hand.
- System failures that trigger no alerts.
- Issues with logging that prevent you from finding the failure causes.
- Backups that don’t work.
- Test automation scripts that fail routinely, etc.
If you experience such issues, it might be worth a return to step 1 of a DevOps implementation strategy and assess the current state.
Maybe, your tools don’t go well with your cloud infrastructure or applications. Maybe, you have organizational issues. Examine it from the perspective of people, platform, and process, not just automation or Agile.
It’s critical to have visibility into the entire DevOps system, which takes into account the process changes and collaboration between teams.
Partnering with an independent company that provides managed DevOps services could reveal flaws in your approach and suggest an optimal way for improvement.
Ultimately, if you want to build better products, you have to be comfortable with constantly tuning and iterating on your direction. You have to brace the processes, the people, and the architecture of the organization itself to take advantage of DevOps.
When you do, you will build great products.
