Just as agile methodologies sit between the business and developers, driving out requirements that are followed by frequent releases of updated code with new functionality, DevOps is the bridge between the development and operations teams.<\/p>\n
![\"DevOps](\"https:\/\/i0.wp.com\/www.markwilson.co.uk\/blog\/images\/devops.png?resize=700%2C152&ssl=1\")
<\/p>\n
This leads to concepts such as infrastructure as code (implementing virtual infrastructure in a repeatable manner using declarative templates), configuration automation (perhaps with desired state configuration) and automation testing. Indeed, DevOps is highly dependant on automation: automating code testing, automating workflows, automating infrastructure – Automating Everything!<\/a><\/p>\n Configuring, managing and deploying resources (for example into the cloud) is improved with DevOps processes such as continuous integration (CI). No doubt some will argue that CI has existed for a lot longer than the DevOps term and that is true – just as virtualisation pre-dates infrastructure-as-a-service!<\/p>\n The CI process\u00a0is a cycle of integrating code check-ins with testing and feedback mechanisms to improve the quality of the code:<\/p>\n In the example above, each new check-in to the version control system results in an automated trigger to carry out build and unit tests. These will either pass or fail, with corresponding feedback. When the tests are successful, another trigger fires to start automated acceptance tests, again with feedback on the success or failure of those tests. Eventually, the code passes the automated tests and is approved for user acceptance testing, before ultimately being released.<\/p>\n Continuous integration works hand in hand with continuous delivery and continuous deployment to ensure that development teams are continuously\u00a0dropping new code but\u00a0in line with the Release Management processes that the operations teams require in order to maintain their service.<\/p>\n Continuous delivery allows new versions of software to be deployed to any environment (e.g. test, staging, production) on demand. Continuous delivery is similar to continuous integration but can also feed business logic tests. Continuous deployment takes this further with every check-in that passes all tests ultimately ending up with a production release – the fastest route from code to release.<\/p>\n No one tool is used to implement DevOps – DevOps is more about a cultural shift than it is about technology – but there are many tools that can assist with implementing DevOps processes. Examples\u00a0include Chef<\/a>, Puppet<\/a>\u00a0(configuration management) and Jenkins<\/a> (continuous integration). Integrated development environments (such as Visual Studio<\/a> and Eclipse<\/a>) also play a part, as do source control systems like Visual Studio Team Services<\/a> and Git\/GitHub<\/a>.<\/p>\n DevOps is fuzzy too. Once we start to talk about software-defined infrastructure we start to look at orchestration tools (e.g. Mesosphere<\/a>, Docker Swarm<\/a>) and containerisation (e.g. Docker<\/a>, Azure Container Service<\/a>, Amazon ECS<\/a>). And then there’s monitoring – either with tools built into the platform (e.g.\u00a0Visual Studio\u00a0Application Insights<\/a>) or third party tools (like those from NewRelic<\/a> and AppDynamics<\/a>).<\/p>\n So DevOps is more than a buzzword. It’s a movement, that’s bringing with it a whole stack of processes and tools to help drive towards a more agile environment. IT that can support business change. But DevOps needs a change of mindset and for me the big question is “is your organisation ready for DevOps?”.<\/p>\n![\"Continuous](\"https:\/\/i0.wp.com\/www.markwilson.co.uk\/blog\/images\/continuous-integration.png?resize=700%2C292&ssl=1\")
<\/p>\nFurther reading\/viewing<\/h3>\n
\n