Octopus Deploy 2.0 Review

Octopus Deploy 2.0 Review

One of the tools that I got involved with this year was Octopus Deploy. Initially, I had my doubts about the product, but I quickly developed a respect for it. A few reasons I like Octopus, it simplifies the whole code deployment process, you can have migrations running in less than an hour. It also has built in Powershell support, so you can add custom functionality to do just about anything else using Powershell. Since it relies on a Nuget Repository to version Releases it makes rolling back code really easy and accurate.

Octopus Deploy 2.0 was announced earlier in the year, and was suppose to be a complete rewrite of the application and containing most of the new functionality that users were looking for. On November 26 the Octopus team announced that Octopus 2.o was going into public beta. There’s a couple of really great features in Octopus 2.0 that I think makes it worth while for current users to upgrade and others to check out.

• Multi-tenancy – 2.0 uses an embedded web server in the Windows service, so setting up another instance is easy as installing another service. This is a great feature for customers with a large volume of Projects
• No IIS Dependency – See explanation above. Because of the embedded web server there’s no need to have IIS installed and running on your Octopus server.
• Improved Permissions Management – In 1.x permissions had to be manually set on each Project/Group/Permission combination, it was a very cumbersome and time consuming process. In 2.0 the Role concept seems to cover most scenarios and makes it easier create a Team that has a certain Role then assign Projects to that Team.
  
• Variable Improvements – Variables can now be scoped to Environments, Roles, Machines, or Steps.
  
• API Enhancements – In version 1.x, parts of Octopus were exposed through a RESTful API but it was readonly. In 2.0 the RESTful API drives the application, so everything that is done in the web portal can be done via the API. I think this is one of the more powerful features because it opens up tons of options for users to create their own automation and customization that ties into the API. If you manage a large hosting environments with many projects you could script projection creation and project permissions.

Of course shortly after getting the Beta running I started tearing into the API. The Octopus team has started compiling some good documentation, but I will warn you its not complete, for example “Teams” is currently undocumented. The good part is the Octopus API is pretty self describing by just browsing to the “/octopus/api” you’ll see the available objects.

Powershell Examples

So let’s get into some Powershell. The following script will create a new Project, and then pull back all Projects.

# Create API Header    
$headers = @{"X-Octopus-ApiKey"="API-QDOPDH264BAA7VCYU2DVZGVKUWS";}

# Create New Project Object
$newproject = @{
  Name="PSTest1";
  Description="Jack";
  IsDisabled = $false;
  ProjectGroupId = "ProjectGroups-33";
} | ConvertTo-Json

# Post to Octopus REST API to Create Project
Invoke-RestMethod -Uri http://localhost:8008/octopus/api/projects -Headers $headers -Method Post -ContentType "application/json" -Body $newproject

Write-Host ""
Write-Host ""

# List All Octopus Projects
Invoke-RestMethod -uri http://localhost:8008/octopus/api/projects/all -Headers $headers -ContentType "application/json"

This example loads a Team object, modifies it, and then saves it. One thing that was not obvious to me was that when using the ConvertTo-JSON cmdlet with an object multiple nested objects, you need to set the -Depth parameter higher. If not I found that the ProjectIds would not be converted into proper JSON and my PUT would return a 500.

# Setup Variables    
$headers = @{"X-Octopus-ApiKey"="API-QDOPDH264BAA7VCYU2DVZGVKUWS";}
$ctype = "application/json"
$uri = "http://localhost:8008/octopus/api/teams/"

# Object Id to Modify
$key = "teams-1"

# Build Full API Address
$address =  $uri + $key

# Get Current Object
$team = Invoke-RestMethod -uri $address -Headers $headers -ContentType $ctype

Write-Host "Raw Output: $team"
write-host ""

Write-Host "Team: " ($team.Name)
Write-host "Projects: " ($team.RoleParticipation.ProjectIds)

# Modify Team Object
$team.Name = $team.Name + "1"

# Convert Back to JSON
# The -Depth parameter is important for Octopus objects with sub nodes
$json2 = ConvertTo-Json -InputObject $team -Depth 5

# Post the updated JSON back to Octopus
Invoke-RestMethod -Uri $address -Headers $headers -Method Put -ContentType $ctype -Body $json2

Gotchas

A few gotchas that I found with the Beta install:

• My install on a Windows Server 2012 R2 would not start due Powershell 2 being missing. This server had Powershell 4 so I’m assuming there’s a check for PS 2 that is failing. I haven’t look closer at how to resolve this.
• Install on Windows Server 2008 R2 failed due missing DLL but it seemed to be related to Windows Authentication, I changed the authentication method to Octopus username and password and was able to successfully install.
• After installing on Windows Server 2008 R2 I was unable to start the Octopus Server due to a System.BadImageFormatException error. I’m going to install on a clean server build.

Conclusion

The go-live for Octopus 2.0 is currently listed as end of January. From what I have seen there’s a few install issues, but it seems like on vanilla systems the install is very clean. The new UI is very clean and responsive, and offers more options for customizing the UI for larger customers. One negative for existing customers is there’s no upgrade from 1.x, that could be a real pain for customers with complex existing installs.