Building Maintenance Processes part 2: Operations routes

In part 1, I outlined how I’m playing around with building a new feature for Octopus Deploy as a way to get back into coding on the core Octopus product. Octopus is designed to help teams automate deployments of their websites and services, but some teams use it for more than just deployment automation — Octopus turns out to be useful for many other types of automation too.

We’ve been calling these tasks “maintenance” or “operations” processes. A typical project has all kinds of these tasks. For example:

• Automatically backing up (and restoring, and testing the backup) a database
• Failing over to a disaster recovery version of the site
• Taking the application offline for maintenance, and then bringing it back up
• Updating the website configuration files (e.g., for new SMTP client settings) without a full re-deployment

We want to add first class support for these types of “non-deployment” automatable processes. When you need to fail over to the disaster recovery site, you should be able to go into Octopus, find the appropriate process, fill in any parameters, and click run. And the same process should be able to be run easily against your Dev and Test environments, so that when the time comes, it will run in Production.

When I left off yesterday, I added my new Operations menu item:

I didn’t have a page to point it at yet, so I just left it pointing to an existing page:

New routes

I’ll start by setting up new routes to point it at. Right now, the deployment process (returned by process.root) is at:

/projects/<id>/process

Instead, I need to change the route to use two diferent pages. There won’t really be a “root” anymore, and I’ll need two pages:

/projects/<id>/process/deployment
/projects/<id>/process/operations

Ideally the code will look like this:

Ctrl+Click in VS Code on process.root takes me to where it’s defined — this is something that never really worked without TypeScript (it would take you somewhere, but not reliably to the place the thing was actually defined).

I added the two new routes, and then changed root to point to the deployments page. And it worked!

But is root needed anymore? I think code using it might need to be more explicit. I’ll see if I can find if it’s referenced anywhere.

Using Find All References in VS Code

This worked surprisingly well, and highlighted all the places where that particular value was used:

I was also curious to see how good the compiler is, so before changing them, I just deleted the property to see what would happen. This made TypeScript really mad!

Compiler errors! I can see why the team like TypeScript so much.

I changed all the references of root to deployment. I think that some of them may need a bit more consideration — for example, the “Add Step” page currently returns back to the deployment process, but it will probably need to selectively return to deployment or operations depending on how you got there. But I’ll figure that out later. At least now the code is more explicit.

TypeScript is happy!

Not so fast there…

Although TypeScript was happy, I wasn’t ready to push my change. I had a play with the UI, but it seems like I broke something. Going to “Add Step” now fails!

Clicking this worked just a minute ago…

But now it fails:

This is the page we return when we don’t recognise a route inside the app.

We also happened to have an automated UI test which caught the bug:

Nice! At this point, I thought: man, we have great automated UI test coverage. I’m super impressed! I wonder what other automated UI tests we have…

We have 4. They happen to all touch the feature I’m working on. It’s like they knew I would be working on this! :-)

As CEO, I wear a good amount of responsibility for this: there’s always a tension between writing more and more tests vs. shipping software. It looks like the team has focussed on some very broad tests — can we log in, add a deployment step, and create a release. I know that we have whole suites of automated tests that test the rest of Octopus from the web API downwards, but UI testing is relatively new. As the boss it’s easy to see “has this shipped yet?” but less obvious to see “is it tested”. I’d love to see a few more high-level UI tests added, and I’d love the team to feel welcome to delay shipping something while they add a few to cover the main workflows of anything we build.

At this point I did some debugging to try to understand what went wrong. Getting the debugger to work with VS Code worked quite nicely, although for some reason I could only set breakpoints in some files, and not others.

I played around some more, and managed to fix up all the links. I realized that it wouldn’t be enough to just introduce the two top-level routes — all the routes underneath this area would need to update the links to either be based on the deployment process, or based on an operations process. So I moved all of the routes for the deployment process under here, and created a new one to prepare for operations.

To make all these URL’s resolve, I had to update some kind of router thing that we use. I’m not sure what that is yet, I should probably read the docs:

Summary

At this point I have my two menu items like yesterday, except they now point to different pages, and I’ve changed all of the child links to include.../deployment to allow me to differentiate them from operations. I tested the UI by playing around with it, but my operations page is currently completely empty.

Takeaways:

• The strong typing from TypeScript makes it way nicer to work on than back when we were using plain old JavaScript in 2015. It’s great to get those compiler errors.
• That said, even though it compiled, I still had a bug. So some level of automated UI testing (which we happened to have in this case) or manual testing is of course still needed.
• Debugging seems to be a pretty nice experience. I need to figure out why it didn’t work for some files though.

Tomorrow I’ll stub out a view. I suspect this will involve becoming more familiar with React, which so far still looks pretty ick to me.