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...

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 shared 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...