DevOps as I perceive it
Someone asked me, are you replacing operations teams with development by implementing devOps? And I said, they are getting wed by means of it.
In typical software development projects, most of the time is spent on feature development. And there is no time to address IT operations issues. Shortcuts are then taken in defining, creating, and testing everything that the code banks on, which includes the OS, DB, network, virtualization etc. Most of us have experienced its influence on delays, inefficient environments, and no repeatable processes to successfully deploy, resulting in poor quality of services.
As a practitioner, I know that these processes span the technology domains in data centers. From development, the process of deploying an application or change to the end-user, requires components from each of these domains. DevOps helps us figure out how to tie them together while still maintaining the specialty and depth of expertise.
DevOps is where individuals still take on skilled “development” or “operations” roles, and work together toward the common goal of delivering a great experience to end user. Developers see the downstream effects of their activities, and enable IT operations to manage issues effectively by way of continuous delivery. Simply said, it is a developer’s view of Operations, and Operations view of Development
It is achieved through the discovery, fine-tuning and optimization of repeatable processes. The majority of time required to deploy an application to the end-user lies not only in provisioning it, but in provisioning it in the context of the entire application delivery chain. DevOps is about how best you can integrate processes from each of these (cross functional teams) into a complete, application-focused operational deployment process. At Mindtree we provide integration solutions that address the make the people and process collaboration easier
Few DevOps frameworks that we implemented for our key customers:
- Making environments available early is all about introducing IT Operations into Development and test their code in stable environments with appropriate tollgates across these environments. In agile we modify the agile sprint policy so that instead of having just viable code (as agile states) at the end of each sprint, we also have ready the environment that it is deployed into.
- Putting Development into IT Operations: We can put Development into the IT Operations chain, possibly in Level 3 support. Or even have development completely responsible for the success of the code deployments, either rolling back or fixing forward until service is restored to the customer. This shortens and amplifies the feedback loops, and brings development closer to the customer experience (which includes IT Operations and the end-users of the service being delivered).
- Instead of having IT Operations responsible for creating the specifications of the production environment, they build an automated environment creation process. This mechanism creates not only the production environment, but also the environments for Dev and QA.
- By keeping sizing variance between the different stages (Development, Test, Acceptance, Production) as small as possible, we find and fix interoperability issues between the code and environment long before production deployment.
- Orchestration Layer: Ideally, the deployment mechanism to be built is completely automated. Tools that can be used include Shell scripts, Puppet, Chef, etc.
Through DevOps, we have been delivering both technical and business benefits to enterprises across Retail, CPG, Travel and transport. Benefits include delivering features quickly to meet demands, more stable operating environments, more time available to focus on added value, continuous software delivery, less complex problems to fix and faster turnaround time.
Welcome to newer possibilities of DevOps 🙂