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).