For organizations seeking a deeper strategic partnership, our Technical Account Management (TAM) program offers a specialized assessment of their software delivery workflows.
Our aim is to enhance the overall experience of using Octopus Deploy for both developers and release management teams, as well as for Octopus administrators.
In this post, I’ll highlight a customer who was using an unsupported ‘middleware’ console app between their ITSM instance and Octopus Deploy, when they could use our ready-made ServiceNow integration instead.
The customer
This story is about a company with customer-specific software configuration changes that need to be deployed on a schedule i.e, once a week or every two weeks. Some changes are HTML or CSS files, while others are SQL scripts that need to be run on their targets.
The customer software configuration changes are collected by the aforementioned console app, grouped together from ITSM’s change requests, and an Octopus tenant is created that links to three projects: One for uploading the files, the other for deploying them, and the last for rolling back changes if the customer rejects them.
This means the company isn’t making proper use of one of Octopus Deploy’s key features - environment progression.
Environment progression allows the customer to progress their code changes in the exact same way through all environments in a lifecycle. And then easily roll back those changes if the need arises.
So the console app creates an Octopus tenant every time there’s a need for customer config files to be deployed. That’s a lot of tenants.
Risks
The kicker is that the customer’s console app is no longer supported by the company’s dev teams because staff have left the company.
- Risk - The unsupported console app is a single point of failure, as if it stops working, then due to the loss of knowledge of how the console app is set up:
- Customer requests will fail to be deployed.
- And repair or remediation will be time-consuming and therefore costly.
- And more importantly, full recovery to a previous working state is not guaranteed.
- Cost - The number of Octopus tenants the console app creates increases daily, with the knock-on effect of increasing license costs at each Octopus Deploy license renewal date.
- Time - While it’s possible to delete tenants:
- This is a time-consuming manual process.
- Involving first removing the tenant from any tagged targets.
- Before deletion can finally take place.
- This contributes to making tenant deletion more prone to human error than it needs to be.
All of the above add other inconveniences too as for example, no one knows how the console app actually works, so they don’t dare change the three project’s steps for fear of stopping deployments. This means those projects are now ‘brittle’, as changing them may stop software configuration deployments.
Unlocking value
As previously stated, the three projects’ settings can’t easily be changed, so it’s also not possible to take full advantage of the following Octopus features:
- Environment progression & rollbacks, by combining the three projects into a single project.
- The customer-change files are also using an outmoded file naming convention, rather than the SemVer versioning schema.
So my further concern is that the company is paying for features that would enhance their deployments, but they are being hampered from using them.
The fix
After further investigation, I decided that, as this company already has a ServiceNow subscription, and as Octopus Deploy has integrated with ServiceNow since Q3 2022, one of the better ways for them to fix this would be for them to use our integration.
This will eliminate the single point of failure and also reduce the risks and costs associated with their multiple ITSM subscriptions.
I began by modelling the customer’s Octopus setup in a dedicated space in my Octopus Cloud staff instance, to gain a true understanding of how they deployed their customers’ changes:
And then I created a second space with my suggested changes:
Which, of course, included using our ServiceNow integration rather than their ITSM + console app combination.
The end result was a five-step migration plan that allowed them to keep their existing setup while they tested ServiceNow and got things working to their satisfaction.
And strictly speaking, the only real changes required were in steps 1 - 4.
Migration plan
Step 1: Request access to ServiceNow and create a separate project linked to that subscription.
As previously noted, this allows the company to keep deploying their customers’ changes using their current deployment workflow, while setting up and testing its replacement.
Step 2: Save those customer software configuration files to our built-in package repository, and save them with filenames that are SemVer compliant:
Step 3: Combine the steps from the three software configuration projects into the new Software Configuration project from Step 1:
Step 4: Add their customers that require software configuration changes as Octopus Tenants to their existing list of tenants i.e, keep the other change request-named tenants as-is.
Then link the Software Configuration project to the customers’ tenants they created. And finally, use Tenant Tags to specify the type of deployment that needs to take place.
Step 5: Create a release for a single customer’s software configuration files in that new project, using ServiceNow to assign the change request number, and then do a test deployment.
Once they are happy that things are working, then roll out the above changes to all of their customers’ tenants.
Finally, complete the migration by archiving the old tenants and disabling the old projects (full clean-up can be done at a later date, subject to any compliance and company retention policies).
Results
- Deployments - These are more easily tracked as each customer’s changes are released in separate deployments.
- Rollbacks - Sometimes customers ask for changes to be rolled back. These can now take place more easily, as each deployment is related to a single customer’s set of files.
- Scheduling - Deployments can be scheduled to happen outside office hours, reducing the need for babysitting.
- Troubleshooting - This becomes easier as each customer’s files are grouped and deployed together, and rollbacks - or roll forwards - can be done as needed.
Savings
The estimated savings are as follows:
Time - Reduce the time spent by release engineers babysitting the upload and deploy projects.
Plus, deployments can now be scheduled, further reducing time spent on them.
Risk - The unsupported console app is gone, removing a single point of failure.
Cost - The need for two separate ITSM subscriptions is also removed.
Conclusion
While it can appear easier to keep sub-optimal deployment workflows, more often than not, the long-term benefits of migrating to better processes far outweigh the short-term pain involved in making those changes.
Octopus Deploy’s Technical Account Managers help our customers achieve their goals and adapt to new deployment patterns, technologies, and services.
Happy deployments!
Tags:
