A question and a suggestion

Legacy Usability
1

We are increasingly using Octopus for all our products.

Q: Although initially for our learning curve we often used (personal) test projects, now we are at increasing speed deploying through Octopus. As our knowledge of Octopus and also Octopus itself develops, as do our products and environments and deployment needs, we are frequently confronted when willing or needing to modify a project with choosing between:
1 - through lots of work create/modify the test project to learn & develop & test the new aspect we need in the production project. And then replicate it manually into the production project, or
2 - have the time and feel confident enough to modify the production project itself, with all the risk having the bonnet fully open when being confronted with a sudden new production release of the product concerned.
Since Octopus already has the process and variables snapshot capability, wouldn’t it be quite easy for you to add an Edit mode to a project which basically takes a snapshot which can be edited and developed and when ready, committed back to the main project. That main project would meanwhile always be available in its stable release state for a sudden production deployment.

Suggestion: During (re-)deployment, especially with more than one person developing and maintaining Octopus projects, when showing the amber warning that something (process or variables) has changed since the project snapshot for this release was taken, it would be really helpful if you could give us an easy view of what has changed. Currently it’s a really hard choice to make… to abandon the deployment and rack one’s head and ask around, or to simply go ahead, or to perhaps update the variables.

Cheers.

3

Hi Nick,

Thanks for getting in touch and thanks for taking the time to detail your issues.

Could we please confirm which version of Octopus you are currently running?

In regards to seeing what’s changed I.e. the deployment warning, we recently added some features (available from version 2018.6.15) so that when a project was changed and you see the warning (either the deployment process or variables for example), we include links to your audit screen so you can investigate and see a diff of what has changed (see the second screenshot from this issue).

Due to the sheer number of things that could have changed since the original release, it’s not easy to show an in-line diff here, so instead we link out to the auditing screen where you can review all possible changes that have occurred to either the deployment process or variable sets. Would this help in your situation?

Regarding your question, we’re interested in your wording around “production project”. It sounds like you have a project with a single production phase in your lifecycle, so making any changes feels incredible risky to you, is that correct?

Are the releases you’re creating moving through a lifecycle with multiple phases (I.e. something like from Dev -> Staging -> Pre-production -> then finally to Production)?

Lifecycles are used as a way of gaining confidence in your release, so you can feel free to edit your project’s process, change variables and so on, because you can deploy to your dev/test/staging/pre-prod environments as often as you wish before you promote that release to production.

If instead, you tend to have lots of smaller projects where you spike out features, then we’re wondering if our “Deploy a Release” step would be useful in your situation? It allows you to deploy a release of another Octopus project. For example, if you spiked out a new feature in Project-X, you’ve tested it thoroughly for days/weeks, then you’re ready to incorporate that into your “main project”, you can simply add it as a step.

A more thorough explanation can be seen in our Coordinating Projects with the Deploy Release Step blog post.

Would something like this work for you?

Hope this helps.

Cheers
Mark

4

Hi Mark,

Thanks very much for your reply.

Could we please confirm which version of Octopus you are currently running?

2018.6.2 while, due to no sign for an avalible update, I assumed we were up to date. My bad, sorry.

So, great news about the project audit/diff screens for detected changes as per Octopus 2018.6.15. Very helpful and just what I was dreaming of!

Re my second question, on further developing Octopus projects without (the risk of) disturbing the frequent deployment of our new Product releases based on the last know stable release of the Octopus project concerned:
Yes, correct, we follow a DTAP lifecycle with multiple phases (5).
We have at the moment about 10 web-based products which all share the same web server/database backend, each product with its own Octopus project. For example, to be more specific, we have three browser-based frontend products Classic (IE 6.0 HTML/js/xml), NextGen (Silverlight plugin) and now Mobile (HTML 5 responsive), and an API for the latter. For each we have developed a rather complex Octopus deployment project which does almost all the necessary work with various steps of various nature. These tried and tested projects have been used intensely since first development last autumn, replacing almost entirely our mostly batch file based deployment procedures. Including mail flow within the organisation, which is great!
But there are still a few last minor steps our Octopus projects don’t yet perform. So now I want to attack those last straws some of which of a challenging nature, and though I’m 100% confident it can be done in Octopus I find myself hesitant to ‘open the bonnet’ on a project for the risk of the project being temporarily broken when a new product release comes in. Octopus project maintenance is just one of my roles and often I can only spend an hour or two at a time. We’ve also moved into CD, Continuous Deployment or Delivery or what ever you want to call it; basically micro releases at higher frequency instead of lower frequency major releases, with all the implications involved (automated testing and smooth automated deployment).

Another requirement we have of Octopus projects is that they remain backwards compatible for previous releases, which on occasion we need to redeploy or revert to. This ties in with my first question and seems to be covered with Octopus project snapshots and the new Change Audit Diff screens.

I can certainly see how we could benefit from the Deploy a Release step, resolving our outstanding dependency issues (Mobile frontend version requires a specific/minimal API version). But I don’t see how it can help me with safely ‘opening the bonnet’ on any project. Of course, for every stable Project we could have a ‘development copy’ which we manually would need to keep in sync and eventually through lots of error prone human work, ‘promote’ to the production project.

To be even more long windedly specific, what I need to do next in one of our projects is add a “Substitute Variables in Files” feature to a Deploy Package step. But this requires correct ACL permissions through AD on all targets on all environments. So it might take me or AD (to propagate) an hour or two, while meantime a sudden new release for the project is created and comes into the automatic deployment. And the risk that the deployment fails at that step because I’m not ready with setting/propagating ACL permissions on all the targets on all the environments/phases. Indeed, there might even be more than one person developing different aspects of the Octopus project at the same time.

I hope I’ve explained myself well. Do you see where I’m heading?
I suppose that basically what I’m seeking is Octopus Project versioning (branching, shelving, merging, committing).

Kind regards,
Nick

5

Hi Nick,

Thanks for the additional information.

Just reading through your scenario, we’re wondering if Channels is something that you’ve considered to help manage the increasing complexity?

For example (assuming you’re not already using channels … other than the Default channel we assign to your project), you could introduce a new channel to your project for these new things you want to start exploring. As you add any new exploratory steps to your existing project, you scope the step to this new channel and that gives you the confidence that “when I deploy to channel-X, only channel-X steps will deploy” so it allows you to do more with your existing projects and maintain clear separation, without having to split things out into separate projects.

This also saves your backwards compatibility issues, as any previous releases will be mapped to a certain channel, so you know exactly what release is deployed to a given channel / environment.

We are looking to improve our story around feature branching, but for now we have this documentation which goes into more detail re. channels and I think this will be what you’re looking for.

Would something like this work for you?

Cheers
Mark