As a _DevOps_ Engineer coming from an Operations background, you will have moved from building and deploying servers and software _manually_ to **scripting** the installation of software onto your servers with the likes of BASH, PowerShell, Python etc. After a while, you would realise how cool scripting is and start to explore more sophisticated ways to **automate deployment**. 

Eventually, you would have settled on a _Chef, Puppet, Ansible_ or other **configuration management** tool to help manage the state of your fleet of systems. As your skills with the automation of application deployment and system management matured, along with your tools, you have more recently moved into the realm of '**Infrastructure as Code**' and use it to not only automate the deployment of software but the infrastructure and environments required to drive the software during the business's shift to the Cloud.

Now you are cooking with gas. Over time you have been introduced to the benefits of using developer centric tooling such as **source control** to manage the modules, recipes and templates that make up your arsenal of deployment and management tools.

When you shifted into the _DevOps_ team you were exposed to the software development life cycle and the concept of **continuous integration**. Boy those developers were releasing changes quickly and to keep up you found yourself working more closely with the devs! You experienced the urgency placed on the development team to change things ALL-THE-TIME which grates against the old operational paradigm of "_if it ain't broke, don't fix it_". No more bragging about system uptime anymore, you are into _disposable_ infrastructure.

You noticed that the move to _DevOps_ was more than working with the _devs_, or using _new tools_ and _techniques_, but there was a distinct **cultural** shift in the team, one that permeated through the organisation at large. You were working as a close-knit team with _sharded responsibilities_, _shared tooling_ and _shared goals_. 

You took your skills in automated deployment and massaged them into the "**CICD**" pipeline being orchestrated by a "**continuous integration server**" like _Jenkins_, _Bamboo_ or _Code Pipeline_. Now, when the developers push new code, your scripts, tools and templates stand up new environments on demand, trigger testing frameworks to do their thing and tear down the pre-production environments after the green lights are lit on the release, adhering to the ideas of "**continuous delivery**".

As the new code snakes its way through the CICD stages, you, the developers and the business gain confidence that the update will not break when released to production. There is some way to go before the team gets to "**continuous deployment**", you still need to settle on the finer points of automating the **blue/green** deployment capability, and the decision is mostly a business one. For the time being you are content that the number of calls at 3am have subsided and the sev-1's and sev-2's dwindle.

Even if you do get a sev-1, you are not pulling all-nighters any longer with the managers breathing down your back - you can easily release the previous version through the CICD pipeline and get the system online again in short order. The business has noticed that the **stability** of the IT systems has improved despite the _velocity of changes_.

You marvel at the way you manage the resources needed to drive the software in your business, especially when you think back to how it used to be and amount of blood you left behind on rails in the datacenter...