Speed is all that matters
CICD and DevOps
There is nothing called a perfect world nor a perfect CICD practice. Organisations will evolve and will mature their practices in coming up with more innovative and agile ways of releasing their code to production. Complexity of software engineering is increasing day by day with applications deployed in microservices, in multiregional failover setups. So reality is more complex out here. How you deploy depends on your application, where and how its hosted, the level of competency of your engineers with the toolsets and your management buy in
The focus of the industry is drifting from firefighting during a deployment failure towards mitigating any failures in the first place by way of defining the pipelines. This practice is evolving rapidly with each passing day, as companies have massively reduced their go-to-market with this approach. In this article, I will touch upon the various approaches organisations adopt in implementing their CICD pipeline. Continuous Integration(CI) and Continuous Delivery (CD)is a software engineering practice where codes are released quickly, iteratively and reliably. It’s a DevOps culture which falls under Agile principles with the sole aim of increasing developer productivity with the abundance of open source tools and compute that is available currently. In this article I try to take a small stab at unfolding the CICD process from my own experience and bringing together pieces of information in one document that is scrambled all over the internet.
CI is a philosophy to check-in code to SCM repositories as often as possible, however small the changes may be. The need to build, package and test the code in a completely automated fashion is the ultimate aim. CD then kicks-in to deploy the code to the application, almost always at a click of a button. The entire process is defined in a pipeline which is nothing but a set of workflows set by a trigger.
The Emergence of DevOps Era
The term DevOps was coined in the latter half of the 2000 decade to bring two communities of developers and operations engineers under the same roof. It doesn’t label itself with any technology or tools, rather it is purely about a new approach - a philosophy of velocity, optimisation and automation.
All current DevOps engineers were erstwhile System Administrators who were involved in configuration management, provisioning, and monitoring of the application and systems. Industry realised that application and its interaction with its underlying infrastructure components could not be made to operate in a compartmentalized fashion. So product teams across the board had to take system engineering folks into their band to achieve a long term value proposition of their product development lifecycle. Thus DevOps became an extension of agile methodology with an emphasis to break barriers between developers and operations teams.
A recent study by Gartner says
“DevOps represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”
For a DevOps engineer, a developer is his customer. So the bulk of work in a DevOps world is often about deployment and getting new releases of the code to production following the agile principles. The coolest thing about DevOps is that there are multiple ways of doing the same job. I have learnt that technologies that meet a need — stay, and the technologies that don’t — wither away. So DevOps is not about a technology or a toolset but more about how you are blending with the cultural shift the industry is drifting towards.
Who is an SRE then?
Though this article is DevOps heavy, I will try to demystify SRE and DevOps briefly here. The term DevOps and SRE are often taken in the same breath and quite rightly so. One is not too different from the other. SRE is couple of years older than DevOps. It was born in Google in 2003. Both advocate velocity and automation with a common goal to get the code to production faster. SRE goes a step beyond to maintain the application conforming to the set SLAs.
SRE is a subset of DevOps in that it implements its very philosophy. From a practical lens, if DevOps lays the fundamental guidelines about collaboration between operations and product teams, SRE is implementation of those practices. As mentioned in the section above DevOps is less about tooling and more about philosophy, SRE is about the right tooling to achieve the service uptime. If we have to draw a parallel with Object Oriented programming, SRE implements the interface DevOps(per Google). I highly recommend reading the free online version of Google’s SRE e-book
Read more on
Staff Manager, Engineering & Infrastructure Services @ Qualcomm
4 年Wellsaid Gaurab!