Maintainability of Octopus Projects

[mark_kharitonov]

Hi,

I think we are doing something terribly wrong with our Octopus projects. I describe our situation here - https://stackoverflow.com/questions/53164512/maintainability-of-tfs-xaml-build-vs-tfs-vnext-build-vs-octopus-deploy

Would you be able to comment and/or answer?

Thank you.

[Shannon_Lewis]

Hi Mark,

Thanks for getting in touch. 50 projects certainly does sound unmanageable, and is certainly not we’d normally expect. The right answer for your scenario will depend somewhat on your needs.

The typical pattern with Octopus is to have a build server with a single build project/pipeline and Octopus with a single project. The build server produces a set of binaries, in the form of a package, and pushes it to Octopus. Octopus is then configured to understand Environments and the Lifecycle you want to use for promoting the binaries through these environments (e.g. Dev => UAT => Staging => Production). Octopus allows you to define variables scoped to each of these environments and does variable substitution into your config files etc during deployment to an environment.

In this scenario the handling of the variables is “backloaded” in the pipeline, rather than “frontloaded” as what I understood from your description.

Could you verify whether Environment here holds the same meaning as what you consider an environment? For some customers, who host multiple versions of their software for different customers of theirs (tenants in our terminology), they sometimes create a completely separate environment per tenant. This is workable but a little more complex to set up.

I won’t try to dig into too much more detail here yet, if I can understand more about your setup then I can provide the right details about the right things.

Regards
Shannon

[mark_kharitonov]

Hi,

Thank you for such a prompt response.

When I am talking about environments I mean our environments. I hope you show me how it maps to Octopus.

Our code naturally divides into three pieces:

[Shannon_Lewis]

Hi Mark,

It looks like your reply got cut off there. Would you be able to try sending again?

Cheers
Shannon

[mark_kharitonov]

Actually, it was sent by accident.

I am still in the process of replying to you.

I want my reply to provide all the information correctly.

Takes some time.

Thank you for your patience.

[Shannon_Lewis]

Sure, no problems.

[mark_kharitonov]

Hi,

Still working on the response - takes time with other obligations, but I am getting there.

Thank you.

[mark_kharitonov]

Hi,

I have prepared a document where I describe the highlights of the current implementation and lay out thoughts on how to improve it. It would be of tremendous help if you could review it and provide answers to the open questions at the end.

The attached archive contains an html page with all the files.

Your help is greatly appreciated.

Thank you.

QADeploymentProcess.zip (1.37 MB)

[Shannon_Lewis]

Hi Mark,

Yes, things like Silverlight and ClickOnce require a non-trivial deployment pipeline, that’s for sure. Whilst I haven’t done it personally, I understand it is possible to build the package once in TeamCity and then have a single project in Octopus that updates the config and signing per deployment.

I think you would be doing most of this already, but in TeamCity rather than in Octopus. This blog post may provide some inspiration, it’s ClickOnce but the concepts would overlap with Silverlight. We also had this response from another customer who found an alternate way of dealing with the configs, which may be of use.

Regards
Shannon