Hi,
I am currently trying to put together a suitable deployment strategy for our website which is being coded by an external partner as well as some internal devs. Both teams work on different features or bugs at the same time and its all getting a bit confusing. The other day, we had the situation where new code from Team A was checked in to our dev environment and then released to test whilst test was actually being tested for a critical bug fix which team B had been working on. This meant we were unable to release code from Team B to live because the testing was not inconsistent as we were then testing team B’s work on new code that team a had released. I am sure this sounds all very familiar for a lot of people and this is the start of our journey so we are probably making some schoolboy errors!.
We want to get to the stage that we can have team A and team B check their code in to SVN (Teamcity/octopus will then automatically package and deploy to dev) but we want to have a way of only releasing the code of team A or B for the features/bugs they are working on to test and then to live. I guess I am missing some understanding at a fundamedntal level with octopus/teamcity because if Team A check in their work and we get a new release of 3.0 and then Team B check their work in and we get release 3.1 and then we want to release team B’s work (i.e. the last team to check in) we think that if we release team B’s work it also includes Team A’s work at the same time or is that not correct? I dont know if this is just the way we have set it all up or if we dont understand something.
If anyone could recommend a way of controlling what is released so that we dont include the original check in that would be great. I realise I sound like a noob to all this and I am!!
thanks,
Paul
Hi Paul,
Thanks for getting in touch! These are great questions, and I’ll try to answer them all. 
The first thing that I think would benefit you tremendously is to implement a branching strategy. Branching will allow multiple teams to work off feature branches to ensure isolation between them. It would be the solution to what you correctly said, we think that if we release team B's work it also includes Team A's work at the same time. There are lots of great resources online that can help you get going.
https://www.atlassian.com/git/tutorials/comparing-workflows#gitflow…
Connect that with our branching documentation, and how Octopus can manage various strategies.
To support a lot of these branching strategies, we introduced the channels feature in Octopus 3.2. Channels allow you to ‘manage multiple active versions of the same project’. Channels are a very powerful tool which allows many things other than just branching, so I’d recommend checking out our documentation.
Additionally, we have comprehensive guides and examples laid out in our channels walkthrough blog post.
You would also want to ensure separation of each deployed release version on your deployment targets to avoid overwriting when deploying. To allow this, you can use multiple Tentacle instances (named for example, Team-A-Test and Team-B-Test) to ensure they’re segregated from each other. You can configure multiple instances on a single server by using a unique port per instance. Check out our doc page covering this as well.
To reiterate, the concepts are:
-
Branching will isolate multiple versions in source control
-
Channels will manage multiple active release versions in Octopus
-
Multiple Tentacle instances will ensure segregation of your versions on your targets
I hope all of this helps get you going. Don’t hesitate to reach out anytime if you have any further questions.
Best regards,
Kenny
Hiya,
thanks so much for the reply it is really appreciated. I am going to get started on this next week
thanks again,
Paul
Hi Paul,
That’s no problem at all! We’re always glad to help. Let us know if you have any further questions.
Best regards,
Kenny