Building Maintenance Processes part 1: Let’s get ready to DevOps.

I started building Octopus Deploy in 2011, and up until the start of 2017 I was still contributing code to the product, although my contributions shrank over time as the team grew. I still code every now and then, but it tends to be for our website, or for data crunching type stuff.

I do miss working on the product, so this month I figured I’d try and build a small feature — and blog about it here in the process. The feature I picked is maintenance processes, which starts to turn Octopus into a more well-rounded DevOps tool.

Since I last contributed code to the repository, a lot has changed. The team converted it from Angular 1 to TypeScript and React in 2017, which is all pretty new to me. I didn’t even have a copy of the Octopus code on my computer, and I wasn’t sure how to set it up.

We keep the code in a private GitHub repository. The team are gearing up for a release, and there’s a lot of features in development, so there’s quite a few active branches at the moment:

Fortunately, the repository has a pretty good Readme that got me started. The code for the Octopus Deploy server is still split into two parts — a .NET solution for the back end:

And a TypeScript/React/Webpack project for the frontend, which I used VS Code to work on:

Once I got everything set up and building — which to the team’s credit, only required installing some prereqs and running a PowerShell script — I thought I’d get dip my toes in the water by making a couple of small changes that have been bugging me for a while, yet never made it high enough on any team’s queue to fix yet.

Change 1: Tenants menu item

The first change I made was to the global navigation menu. Octopus has a feature called multi-tenancy, which makes it easy to model deployments to multiple tenants. Not every customer uses it, so for some reason we put it into an Addons menu, which… only contained Tenants. The original intent as I understand was that we’d put other not-commonly-used features there soon, but those haven’t shipped yet, and it just looked weird.

If a customer hasn’t used the multi-tenancy feature, the menu item appeared under an “Addons” menu.

If we’re going to waste the space with a tab called Addons to hide a tab called Tenants, we may as well just show the Tenants tab. So my first code change was simply that:

Just make Tenants always appear.

The code change for this was pretty simple, I just had to find the right TypeScript file and modify it.

The Addons menu was clearly intended to have other menu items in it someday, but that day hasn’t come yet.

It worked! I committed my change and pushed to master. A few minutes later, Slack piped up to tell me I broke something:

We use TeamCity as our build server, and there’s a Slack integration that notifies us if we break the build.

It turns out that we had an automated UI test that tested that this menu only appeared conditionally. I remember when we were on Angular 1, we had zero automated UI tests — we only wrote tests for the API down. I’m really pleased the team added end-to-end UI tests.

Fixing the test was incredibly easy:

These tests use Selenium, but the team have done a very nice job of making the code easy to read with just the right abstractions.

Overall, I really enjoyed the experience of making this change. I still find React code hard to read, but it’s great to Ctrl+Click your way through the TypeScript classes until you find what you are looking for. I really love the end-to-end UI tests the team have built, and the experience of (a) knowing I broke something, and (b) how clean the test was and easy to fix.

Change 2: Code fonts

My next change was another annoying little bug: we have a placed where we used monospace fonts that just looked way too big or too small for me. From what I can tell, we didn’t explicitly set these when we rewrote the UI, so I don’t think it’s a deliberate decision that we made, more just an oversight.

I’m almost embarrased to admit this was the #2 change I decided to make in Octopus — it’s very trivial!

The font used for the names and values of these variables just felt too big.

The code editor font felt proportionally too small.

Now this should be an easy change. I know CSS quite well, so I’ll just right-click, Inspect Element and…

…gouge my eyes out with a spoon.

I don’t think this is unique to our project, as it seems to affect other applicatons that use React. Instead of a nice CSS file with everything, a lot of stuff makes its way into styles on a per-element basis. I think this is to make the controls more composable and avoids the big-ball-of-CSS-mud.

Making this change took a bit longer than the first, but turned out to be pretty easy once I found the .less file. It looks like we tend to keep them next to the components:

Change 3: Operations menu

With those quick changes out of the way, it’s time to make a new feature branch, and start working on my feature. The goal of this feature is to give you the ability to not just use Octopus to deploy software, but to use it for all the other kinds of automation you want to do.

I figured I’d start by changing the menu item to make provision for the different kinds of processes.

My shiny new menu item. I started with Maintenance as per the Balsamiq mockup, but decided to try Operations instead, to see if it sticks.

This was super simple. The project menu is, again, in a TypeScript file, and everything is strongly typed, so it was easy enough to modify:

I don’t have anywhere to point my new “Operations” menu item to, so for now I pointed it to the variables page. Which means it highlights if I select variables:

Summary:

All up, it was probably about 3 hours to get the code, get it running, and make these changes (and fix the test I broke). My key takeaways:

• I think the engineering team at Octopus is clearly more mature than it was when I last wrote production code, kudos to them! Having actual, working, end to end UI tests is great. And they seem like very well-written tests.
• The decision to use TypeScript seems like a good one — it’s definitely easier to navigate the code and I feel more comfortable making changes than in 2016.
• React still looks messy and ugly to me. I’m sure this might just need getting used to.
• Never “inspect element” in a React application.

I’m not sure when I’ll progress on this feature next — it could be tomorrow, or it could be in a few weeks — but when I do it will probably help me if I have a plan for what to do when I pick up this project. So I think my next step will be to start to build the “Operations” page.