RFC Remote Release Promotions

Disclaimer: this is an old post I meant to publish back in late May 2017.
Octopus is on a roll of sorts, trying to come up with new features to meet customers desires from UserVoice. The latest RFC for Remote Release Promotions is one of those features that you either need or don’t. I see no middle-ground with this feature, but it’s important to have as I can easily imagine having scenarios where this feature is an appropriate fit. To summarize my understanding of the RFC: some teams cannot deploy across all environments using Octopus due to either physical locations (network boundaries) or security (PCI compliance, etc.). This RFC task is to allow those projects or teams to have two octopus servers that can share a release from one octopus server to the other seamlessly.
Conceptually, the notions of spaces ties everything together however it’s still not as simple as it sounds to promote a release between two spaces. While the Octopus team admits they haven’t figured this all out yet in detail, they’re trying to solve a problem that’s more common than most realize (including myself). Since my work doesn’t have this strict separation or partitions between physical networks or distances or logical boundaries for security purposes, this approach or “Remote Releases” makes sense – albeit it’s a head scratcher at first sight. It’s taken me some time to mull over these ideas and proposed changes or additions and as someone who would not need this type of feature, I really had to contemplate the mechanism to achieve the feature’s goals – but not the actual utility of the feature itself.
Update 2017-11-27
Octopus has a nice explanation on their blog post in regards remote release promotions, but it’s still takes a little imagination to pull this off. I don’t expect to be using this type of feature in the near future for myself, but for those projects/companies that need something like this, I would go out on a limb to say that Octopus would be practically the only solution that comes close to pulling off a feat of this nature. Using LifeCycles as the bridge between two Spaces (and thus creating the “trusted” space concept) – everything fits within the conceptual model of Octopus albeit to me, it feels like remote releases seem or behave like a target role but it requires a lot of configuration to encapsulate context and bleeds into LifeCycles, Spaces, Variables, etc. and ultimately a few new concepts need to be created such as trusted spaces, release bundles, and deployment receipts.
Spaces are the conceptual representations of Octopus instances now and the trusts are the secured connection between the two. Since instances of Octopus are independent of the servers on which they reside, one space can live in one datacenter (e.g. Azure) and another space can live in another (e.g. AWS) but with stricter security between the two for security compliance. Lifecycles define the context between spaces (as do Source Space and Target Space) and their corresponding environments (aka Remote environment). As I mentioned before, everything fits fairly well within the Octopus domain. Trusts need to be added since communication between disconnected Octopus servers need some sort of authentication; it’s hard to argue that it’s not necessary. Could trusts have relied on API-keys? Maybe. X.509 certs may be more secure as all tentacle communications rely on self-signed certs so maybe it’s a toss up of which authentication methods is better. The key point is that those trusts make sense. But beyond this concept of trusts, source/target projects, environments et. al, gaps start to appear and admittedly, Octopus is still trying to figure things out but it’s hard to be critical of something that doesn’t exist yet.
I would suggest reading the RFC for yourself as my paraphrasing/regurgitating of their content wouldn’t be worth the effort. My initial take on Remote Release Promotions was a little guarded, but for my own use case – I would seldom if ever need this type of functionality. That’s not to belittle the feature itself as I’m well aware of the need for other organizations as a feature like this would be a significant benefit. After reading the blog post on Remote Release Promotions (several times), its a much more clearer story with some vague areas that still need to be worked out (again, even Octopus admits this).
Overall, I think this feature may take a few iterations. Historically, new Octopus features have been smaller in scope but the impact they’ve had I’d say is totally worth it (LifeCycles especially comes to mind). Features like Triggers, Subscriptions and perhaps Deployment Targets (cloud and elastic environments) are by comparison smaller in scope and have a few refinements over time but again the features are definitely worth while. Remote Release Promotions seems to be on par with (or perhaps greater than) the multi-tenancy feature. It’s a big change that is extremely helpful if you need to use Octopus in that manner. I don’t use multi-tenancy because I don’t have a need for it – but it being there at the ready is at least worth something if and when a situation arises. Remote Release Promotions is a big feature that spans several major domains within the Octopus domain model, but it is well worth it if that feature is something you need.
Now with v4.0 being officially released, Remote Releases have not made an appearance yet. I can imagine this feature coming out in the next three to six months in 2018. I would be interested to see this feature in action judging by the way their architecture looks. From a usability standpoint, I think there’s a lot of work to be done because nothing about this feature suggests “simplicity” but again, there’s really nothing to see yet so that judgement is clearly pure speculation.
Kudos to the Octopus team for rolling out version 4.0! I’ll have a review on version 4.0 within the next few days.