Tag Archives: Release Management

What does #DevOps mean to the roles of Change & Release managers?

What does #DevOps mean to the roles of Change & Release managers?

One of our team raised this question in our internal #DevOps Slack channel this week and it sparked off an interesting discussion that we thought was worth sharing with a wider audience.

Firstly, let’s start with one of my favourite definitions of DevOps:

“DevOps is just ITIL with 90% of stuff moved to ‘Standard Change’ because we automated the crap out of it” – TheOpsMgr

Now that’s a bit tongue in cheek, obviously, as the scope of DevOps in a CALMS model world is probably wider than just that but it’s not a bad way to start explaining it to someone from a long-term ITIL background.

They (should) know that a Standard Change is:

“Standard Changes are pre-approved changes that are considered relatively low risk, are performed frequently, and follow a documented (and Change Management approved) process.
Think standard, as in, ‘done according to the approved, standard processes.”
http://itsmtransition.com/2014/03/name-difference-standard-normal-changes-itil/

If we break that down into the 3 main parts we get:

  • relatively low risk” – DevOps reduces the risks via automation, test-driven development (of application AND infrastructure code), rapid detection of issues via enhanced monitoring and robust rollback.
  • are performed frequently” – this is a key tenet of DevOps… if it’s painful, do it more often, learn to do it better and stop trying to hide the pain away!
  • follow a documented (and Change Management approved) process” – DevOps is about build robust digital supply chains. This is your highly automated, end-to-end process for software development, testing, deployment and support and as part of that we are building in the necessary checks and balances required for compliance to change management processes. It’s just instead of having reams of documentation the automated workflow *IS* the documented process.

This starts to point us in the direction of how the role of the Change & Release Manager will change over time.

In the same way that the role of IT Operations will become more like Process Engineering in a factory the role of Change & Release Management will start to focus on more on the digital supply chain & software production line rather than trying to inspect every single package that flows along that pipeline.

In this way they become more like quality control engineers in that their job becomes to work with the process engineers to design the pipeline in such a way that what comes out the other end meets the quality, risk and compliance criteria to be considered a “Standard Change”.

They also need to move towards more sampling-based, audit-style approach for ensuring that people aren’t skipping steps and gaming the systems.

For example, if the approved process says that all changes must pass automated regression testing they might periodically pick one release and review that the regression suite was actually testing meaningful cases and hadn’t been replaced with a return:true; because no-one could be bothered to keep it up do date.

Similarly, if the process mandates “separation of duties” they could check so see that the person who initiates a change (via the pipeline) isn’t also in the same role required to approve the Jira ticket that Jenkin’s checks to see if that release can be deployed to Live.

The overall goal here is to move towards a “High Trust Culture” but keeping in mind the mantra of “Trust, but Verify” they need to work with DevOps to ensure the appropriate checks and balances.

That, and never, ever invite me to a CAB meeting, ever again. :-)

-TheOpsMgr

The DevOps Revolution

“We transformed from a team of employees to a team of owners”– Jim Stoneham, Opsmatic

In a fascinating interview with Opsmatic’s Jim Stoneham Gene Kim revisits Flickr’s innovative 2009 ’10 deploys per day’ presentation.

Comparing different approaches to tackling the rapidly evolving platforms within Yahoo! Stoneham highlights the benefits of integrated working across departments, taking risks in order to learn and involving everyone, at every level with every element of the deployment process.

Working quickly, deploying frequently and developing on the fly means that teams learn faster from mistakes and are able to remain ahead of competitors, as well as responding intuitively to the needs of their audience. Teams are also more involved in the process – collaborating across departments means that everyone learns more and the product belongs to the team as a whole,  because they are all involved in every element of its creation, deployment and improvement.

Sharing knowledge and experience across teams means huge pools of resources at your fingertips. You can monitor your audience and give them what they are asking for as they need it. Working slowly to avoid risks will just lead to missed opportunities and an overall slower development. Frequent deploys and rapid responses to audience needs are vital:

When you move at that speed, and are looking at the numbers and the results daily, your investment level radically changes. This just can’t happen in teams that release quarterly, and it’s difficult even with monthly cycles.” Jim Stoneham

Check out the full interview; a  genuinely interesting insight into the start of the DevOps revolution.

Automated release management for .NET with OctopusDeploy

Introducing OctopusDeploy

We are big fans of OctopusDeploy and have been using it since its beta release in early 2012. If you’re not familiar with OctopusDeploy, here’s the background;

1. It’s an automated release management tool for Microsoft .NET, comprising of a centralized server and agents, known as Tentacles, which are installed on each target server.

2. It uses the NuGet package format,  an open source package manager for the Microsoft .NET Framework.

3. Tentacle agents listen on TCP port 10933 by default and HTTP requests are encrypted using a pair of X509 certificates.

The following diagram shows the release management components;

Deployment Components
Deployment Components

Release Management On-premise or Off-premise

One of the highlights of using OctopusDeploy is its’ ability to deploy software to servers located in any environment. The highlight reel goes a little something like this;

Whether your servers live in the cloud, in a data centre, or under your desk , Octopus can securely upload, install and configure your applications.

Just install a tiny service agent called Tentacle on your servers, and then use our easy installation wizard to set up a secure connection between the Octopus and Tentacle based on public/private key encryption technology. Your server is ready for deployments!

We’ve installed OctopusDeploy many times and have used some of the following installation scenarios to deploy to on-premise and off-premise data centres.

Scenario 1: On-Premise Installation with On-Premise Deploy

One of the more common ways of installing Octopus is one where the NuGet Server and Octopus Server are located on your own network,  along-side Continuous Integration servers or source control systems.

In this installation, OctopusDeploy will pull NuGet packages from a NuGet Server (such as MyGetJetBrains TeamCity, a NuGet Feed Server or just a local file path) and push the deployment out to target servers located on a local network.

Since all servers are located on the same network, this configuration is straight-forward and requires not much more than Windows Firewall configuration to be completed,  where TCP traffic over port 10933 (presuming the default ports) is allowed between the OctopusDeploy server and the target servers.

On-Premise Installation with On-Premise Deploy
On-Premise Installation with On-Premise Deploy

Scenario 2 :On-Premise Configuration with Off-Premise Deploy

This installation presumes that your target servers are not within your own network. E.g. hosted in an off-premise data centre E.g. a cloud environment. Configuration is the same as Scenario 1, and Windows Firewall will still need to be configured.

However, in this scenario it is likely that additional layers of security will be in place E.g. a hardware firewall. Network teams will need to ensure that TCP traffic on the OctopusDeploy port (10933 by default) is allowed into each server.

This deployment scenario has some complications however. Each target server needs to be publicly addressable. For load balanced server farms this is going to add a level of complexity, as firewalls and content switches/load balancers will need to be configured to allow each target server to be individually and publicly available to an external caller.

More common, is the fact that servers located in the off-premise data centre might not be publicly addressable with good reason. E.g. Web Servers in a DMZ can receive traffic originating from public networks, whereas application and database servers (and firewalls) are configured only to receive traffic generated within the off-premise data centre.

If you do decide to expose servers publicly to allow Octopus to deploy from an on-premise to an off-premise location, you can take some solace from the fact that the Paul Stovell from OctopusDeploy has ensured deployment is secured with HTTP requests that are encrypted using a pair of X509 certificates.

On-Premise Configuration with Off-Premise Deploy
On-Premise Configuration with Off-Premise Deploy

Scenario 3 :Off-Premise Installation with Off-Premise Deploy

Finally, you might want to consider a scenario where the Octopus Server is hosted within the off-premise data centre that software will be deployed into.

The NuGet server can remain on-premise in this scenario. Since Octopus will generate outbound HTTP (TCP:80) traffic to a known destination ( in our experience ), security guys (not all) are cool (don’t complain complain less) with this approach.

Advantages over Scenario 2

1. Octopus and target servers are now located within the same network, or are on trusted networks.

2. Servers do not have to be made publicly addressable. Non public servers can be deployed to.

3. Load balanced challenges in Scenario 2 are overcome. Octopus can now individually address all servers.

4. Deployment time can be reduced, as NuGet packages are transferred once from NuGet source and are deployed across local or trusted networks.

Disadvantages

1. Additional server infrastructure is required in data centre to host OctopusDeploy Server.

Off-Premise Installation with Off-Premise Deploy
Off-Premise Installation with Off-Premise Deploy

We hope that’s given you a flavor of the installation scenarios available to Octopus Deploy! More information on OctopusDeploy can be found at http://octopusdeploy.com

DevOpsGuys use Octopus Deploy to deliver automated deployment solutions – ensuring frequent, low-risk software releases into multiple environments. Our engineers have deployed thousands of software releases using Octopus Deploy and we can help you do the same. Contact us today – we’d be more than happy to help.