Our current setup (for development) is that we have a Default Web Site with several subsites (APP_Develop, APP_Staging, APP_Production), this is on our dev servers for testing and building.
In production, currently we have the same setup (soon we will be upgrading to separate servers). We have one server with APP_Staging and APP_Production with host headers set up.
Since I am new to Octopus - this is throwing me off. How should we set up “Environments” this way? My brain can’t seem to comprehend this.
For your Development Environment, I’d recommend you to setup a single Tentacle on your server, and then on the Octopus web portal add that Tentacle to all the environments (see screenshot 1). From there It’ll just be a matter of creating all the Environments you need per sub-site. See attached screenshots for visual reference.
For your Production Environment you could do the same, but I strongly recommend you to jump to “Tentacle per Server” as soon as you separate them like you said you will.
Thank you for this, it is very helpful. My next question pertains to branching, I have read the following article:
And unfortunately we have been using the one “not recommended” and disliked strategy of different branch per environment.
I guess I need to change the way I think of deployments and branches now that we are switching to octopus deploy. Is there a certain “best practice” for branching with Octopus (I’m not opposed to changing our strategy)? Currently the user base is small, but the hotfix / deploy strategy is cumbersome and requires lots of merging and switching between branches.
I read the “Build your binaries once” article, but how does that work if you have a “develop” environment for new features / fixes / code, and a production / staging environment? Maybe I am missing how to connect the dots with Octopus.
Would you like to have a call to talk about that strategy? It’s probably gonna be easier to talk about it rather than writing a huge reply that might not exactly fit your needs :).
