Tag Archives: Release Management

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.