Dear support,
I am actually evaluated octopus for our continuous deployment process.
We have TeamCity which is capable to push package to Octopus after successful build.
Package goes into the Octopus package repository.
Then from Octopus I have configured 3 different environment as DEV, TEST, PROD as well as linked target with same name.
As it is the first time I am using Octopus I have few question
Q1 -
In order to deploy the package push by Teamcity to the first Target DEV for instance, is it a manual operation by clicking on Deploy Button or can it be fully automatic ?
Q2-
Once a package is deploy to the first Target DEV for instance, deploying to the TEST environment is it from a manual operation all time by clicking the Deploy to TEST button ?
Thanks for getting in touch! I believe you have a couple of options for achieving what you are after here.
First, I will recommend our documentation on using TeamCity with Octopus if you have not already seen it. This guide has instructions on integrating TeamCity with Octopus and provides a lot of valuable information including triggering your release/deployment directly from TeamCity.
The benefit of this approach is your build server will show and report a failed deployment as a failure in the case it was unable to deploy, in the case where it was successfully deployed it will show green/success.
The other option is to have TeamCity create the release and use the Lifecycle option in Octopus to automatically deploy when a project enters the specified stage of the deployment. See Lifecycles documentation (Step 7 under Create a New Lifecycle)
Does this help?
Let me know if you have any further questions here or run into any issues.
Hi Daniel,
I have already integrated octopus with Team City and when each build gets successfull the package is generate using Octopack and push to octopus feed url. This works nicely.
Based on Release generation, when Team city succeed building the package is send to Octopus Server, then I have create a Trigger phase that as mention in step 7 of LifeCycles documentation and I have set the option in octopus to create automaticaly a Release. Then At that time the release is Automatically send to the First deployement environement which DEV.
This works now but I have still 2 question to complete my basic evaluation and present the demo to my team …
Q1 : My TeamCity server is triggering a continuous build as soon as a file change on our version conctrol system. At that time if sucessfull anew package will be sent to Octopus and a New release will be created through the trigger in place and then push to DEV. So that means that I will have all time the last version of my TeamCity build on my DEV environement correct ?
Q2 : What typicall type of sequence and what trigger then is deploying from DEV to TEST, is it manual operation ?
Idea is that on my DEV I should have a continuous release increment which is all time the last version. Then on TEST we should decide based on some condition when this DEV release goes to TEST but how ?
Thanks for getting back with some more information about your current configuration. Hopefully I can provide you with some helpful answers below.
Q1 : Correct, if you are telling Octopus to create the release as a part of your build in TeamCity, then using the automatic deployment function for the Lifecycle phase, each time you create a release for this project it will automatically deploy the latest version of the package to DEV.
This was initially a limitation in Octopus before we created Channels to give you a little more control here. Channels essentially let you configure Version Rules to more dynamically select packages and Lifecycles for your deployment or implement a branching solution. The documentation on Channels is extensive and worth looking into if you need some more functionality here. You may not need Channels, but I thought I would like them as they provide some more options here.
Q2 : This is really up to you I believe. Default operation in Octopus is manual deployments, however we have multiple options around this. If you want something automated but dependent on machine related conditions, check out our Project Triggers feature.
As the Test deployment is not set to automatically deploy, you could just leave it to be manually deployed. Alternatively, for some more control here, you can create a Manual Intervention step as the first step in the Project and scope it to your Test/Prod environments. This intervention can be assigned a team so only members of that team are able to “Approve” the deployment after it starts. This essentially stops the deployment before any step run and waits for input.
Above may be a fairly general spread of features and ideas but they should provide you with some ideas or thoughts here. If you have any more specific questions here please let me know, I’ll do my best to help.
