DevOps is still a buzzword, despite being a decade-old. The point is, there is no strict definition of what is DevOps and what it is not, so many self-appointed experts and “gurus” describe whatever process they can perform and call it “DevOps”. We have quite often heard that a DevOps team is composed of all-around capable software engineers that are cross-functional and can code, test the code, deploy it and run the infrastructure in production.
There is nothing more miserable and wrong than this definition. We can tell this for sure, as IT Svit is rated among the leaders of Managed Services Provider companies worldwide and providing DevOps services is our core expertise, as you can check on our site https://itsvit.com/services/devops/. This article explains who such talent really is and what is DevOps engineer actually capable of.
DevOps: a combination of goals, not skills
DevOps methodology is actually a practical implementation of the Agile philosophy that fosters communication and collaboration between all the team members and teams in your business. Just imagine a standard Git-based workflow (assuming your business uses issue-tracking systems and not just communicates in the chat):
- A developer writes the code and creates a ticket for a QA to test it – and starts working on another task
- A QA engineer most probably is testing something already and does not respond to the new task at once. If a testing environment required to test the new batch of code is readily available, it will be tested in some time. If not — a QA creates a ticket for an Ops engineer to configure the testing environment needed for this task.
- An Ops engineer has his hands full managing the infrastructure and responds in some time. In the best-case scenario, he spends some time provisioning and configuring the required testing server and the testing can begin the same day the task was issued. If not, this is postponed until the next day.
- If the code passes the basic testing successfully, it can be pushed to the main project repo, a new app version must be built and pushed to the staging server, where the new build must be deeply tested before releasing it to production. Another series of tasks for an Ops engineer.
- If the code does not pass the test, the QA returns it for bug fixing to the developer.
Rinse. Repeat. This approach is a daily routine for millions of businesses, especially the ones forced to maintain a legacy infrastructure with legacy workflows. Everybody is frustrated, software delivery schedule is unpredictable, releases are infrequent and can cause huge downtime, as the production environments can differ greatly from the IDE, testing and staging ones, which can cause post-release crashes.
This leads to an endless debate about what is more important — faster development of new features or stability of system performance in production. The goals of different parts of your business are not aligned, the responsibility is often tossed over the wall and nobody wants to take the blame for systematic errors — people just quit hen they are fed up.
But this is not so for the companies that had undergone the DevOps transformation. During this process, a DevOps engineer explains to everyone that he runs the code 90% of the time of its lifecycle, with the development and testing taking merely 10% of time together. Thus said, the DevOps team has the final say in the questions of software delivery.
Therefore, every new project starts with aligning the goals of the Devs, QA and DevOps by discussing WHAT the new product/feature/service must do, HOW it must be structured to be scalable, secure and be monitored easily, HOW to ensure this during testing and HOW to develop the product with this in mind. After a consensus is achieved on these goals, the DevOps engineers build a CI/CD pipeline for the project: they provide a series of scripts (Terraform and Kubernetes manifests, Ansible playbooks, Jenkins workers, etc.) that automate nearly every aspect of the software development operations.
For example, a standard DevOps CI/CD pipeline is as follows:
- a DevOps prepares all the needed scripts and configures all the tools ONCE
- a developer writes a codebase of unit and integrity tests and regularly updates it.
- a developer produces a new batch of code and tests it at once y running a corresponding script
- if a test fails — the developer fixes the bugs at once
- If testing succeeds, the code is pushed to the central repo, a new app version is built and pushed to the staging server for the QA engineer to test it — all this is done AUTOMATICALLY
- if the tests on the staging server are successful – the QA can publish the new feature to production at once — or store it for a bigger release later.
- The DevOps engineer monitors the system, improves the scripts, thinks on the ways to further improve and automate operations — instead of constantly putting out the fires.
This is not a fantasy, it is a daily routine of IT Svit operations and every customer can check it out for themselves. Do you still have any doubts that you need a DevOps engineer? Contact IT Svit and we will show you what is DevOps engineer really capable of!