And let’s say that the application is deployed in production as version 1.4.0, and we are currently working on version 1.5.0.
This is what we want:
On each commit, Teamcity pushes and deploys to DEV(A).
Each night, Teamcity promotes DEV(A) to QA(A) and then runs integration tests. If successful, Teamcity then promotes QA(A) to DEV(B). So this is a general lifecycle for the development team of that application. I guess you could say that DEV(B) is really also production but it is not the same server as PROD. We are only talking about pre-releases here obviously…
This is for the latest and greatest (what will become version 1.5.0).
We need to be able to push a hotfix version 1.4.1 also. This would use the same logic / cycle as 2).
How would you draw our setup, with lifecycles, channels, multi-tenancy etc?
Anything unclear, please ask.
Any comments are welcome, though I have tried to follow the documentation (e.g. for multiple versions etc) I always seem to end up with something that doesn’t do as expected - probably because I’m not using Octopus in the recommended manner.
So it would be great if you could comment on a setup of “stuff” in Octopus on how to setup our requirements, and then I can use the documentation to get the details implemented…
Thanks for getting in touch! I do believe that Channels are your best option here. From what you have laid out, you need to be able to do the following:
-Managed the deployment pipeline of your pre-release deployments.
-Dynamically select which Lifecycle a certain build needs to be deployed through.
-Deploy hot-fixes.
Channels are designed with just this in mind. You are able to create a Channel for each different pipeline/Lifecycle you wish to deploy to for each project. As a basic example you could have something like this:
Channel-A: DEV(A) -> AQ(A) -> Dev(B)
Channel-B: QA-(B) -> PROD(A) -> PROD(B)
Channel-Hotfix:(Any Lifecycle you need to hot-fix)
Again this is a basic idea to convey the concept :). When you create your channels, you are able to define a version range, perhaps you only want myApp.1.4.1-preRelease to go to Channel-A. You can define the version rules in that channel so if you automatically create a release from your build server, Channel-A will automatically be selected for all of your -preRelease tagged versions.
Our Channels feature is quite extensive, though our documentation is just as extensive. Should you have any questions at all, or if I have misinterpreted your needs, please let me know.
Thanks - I will try to create a new project and setup our suggestions this weekend. A couple of questions that comes to mind:
Shouldn’t/couldn’t this be combined with multi-tenancy?
For example to be able to support PROD(A) and PROD(B) configuration differences of the same application.
How would I deal with deploying automatically. As we use Teamcity and the “OctopusDeploy” build steps, I’m kinda forced to specify an environment (it is mandatory) when invoking the “OctopusDeploy: Deploy release” build step. But since the build in question could be any (release, hotfix, dev, feature branch etc) I would like to just let Octopus decide based on the rules in channel/vesions etc.
But that seems to be only available when environments are changing. I “just” need something that kicks in when a release is created from Teamcity, and let Octopus handle where it is deployed…
How did you go here? I believe you could technically do it both via Tenants or Channels, Tenants are especially handy if you are deploying multiple versions of a site to the same target, Channels are useful for managing different branches.
In regards to your second question, if you are using the TeamCity plugin, you will only need to specify that a release needs to be created. For each Lifecycle you have, you can specify that it should automatically deploy if a release enters the phase. So for automation, you can have each Lifecycles first phase set to automatically deploy, leaving all your promotions requiring manual deployment.
Let me know if the above answers your question, or if you have any further questions.
It has been postponed for this weekend because I’m missing some understading. The automatic deployment was kinda hidden in the “Add environment” dialog, but I see it now.
I understand that a release is deployed to, say DEV environment when “the release enters this phase”. But HOW does the release enter this phase? I’m missing understanding of the mechanics here…
For example:
From Teamcity, I create a release using the “OctopusDeploy: Create release” step. Here I do NOT specify channel, environment, tenants or anything. I just make sure that the release is created in Octopus, say “Website.1.0.1-dev-123”.
What logic in Octopus kicks in now? How does it enter the first phase of a specific life cycle?
Thanks for getting back. So when the release is created, it “Enters the phase” of the first environment in the Lifecycle. So in Dev-Test-Prod, creating a release would enter into the Dev phase, which is where the “Deploy automatically when entering this phase” comes in.
As for how Octopus can decide which Channel/Lifecycle to use upon the package being pushed / release being created from TeamCity. This is handled by plugin, which uses Octo.exe. The following link has a list of command line arguments that can be passed to octo.exe from your TeamCity create release step, including things like -channel and -tenant.
Let me know if this clears things up or if you have further questions here.
Well I’m hitting an obstacle here. I’ve setup my project with channels and versioning. The project (and the channels) are using my “dev/test/prod” lifecycle. However here comes the first problem: On the “Overview” of my project it does NOT show the correct lifecycle.
Anyways, I created a build step in Teamcity that pushes and creates the release in Octopus. I’m not specifying any channels or anything - just the Project name, Log from TC says:
[14:47:01] [Octopus Deploy] Finding project: InfoWeb
[14:47:01] [Octopus Deploy] Automatically selecting the best channel for this release...
[14:47:01] [Octopus Deploy] Building a release plan for Channel '4.7'...
[14:47:01] [Octopus Deploy] Finding deployment process...
[14:47:01] [Octopus Deploy] Finding release template...
[14:47:01] [Octopus Deploy] Building a release plan for Channel 'Latest'...
[14:47:01] [Octopus Deploy] Finding deployment process...
[14:47:01] [Octopus Deploy] Finding release template...
[14:47:01] [Octopus Deploy] Selected the release plan for Channel 'Latest' - it is a perfect match
[14:47:01] [Octopus Deploy] Using version number provided on command-line: 4.8.0-dev-1456
[14:47:01] [Octopus Deploy] Release plan for InfoWeb 4.8.0-dev-1456
[14:47:01] [Octopus Deploy] Channel: 'Latest' (this is the default channel)
[14:47:01] [Octopus Deploy] # Name Version Source Version rules
[14:47:01] [Octopus Deploy] --- ----------------- ---------------- ---------------- -----------------------
[14:47:01] [Octopus Deploy] 1 InfoWeb 4.8.0-dev-1456 User specified Range: PASS Tag: PASS
[14:47:01] [Octopus Deploy]
[14:47:01] [Octopus Deploy] Creating release...
[14:47:01] [Octopus Deploy] Release 4.8.0-dev-1456 created successfully!
So it seems that went alright with the correct channel. Octopus audit confirms this. However nothing happens in Octopus. My “Dev” step in that lifecycle is set to auto-deploy on entering that phase.
The “auto deploy logs” under diagnostics are empty…
What could be the problem here? Why isn’t it deployed to tenants? Something fubar with the lifecycles (since the overview shows the wrong lifecycle) or perhaps I’m a victim of this GitHub issue:
Thanks for getting back! it looks like you may have run into the following issue. https://github.com/OctopusDeploy/Issues/issues/3594
I have added your details and a link to this ticket to the GitHub issue.
Some things that could help here. Would you be able to confirm that at least one of your Lifecycle phases for dev are mandatory? I believe at least one phase needs to be non-optional to avoid this error. After this, could you please run a Check System Integrity on the Configuration->Diagnostics page, then attach the results?
Looking forward to hearing from you and getting to the bottom of this one.
Unhandled error on request: http://localhost/octopus/api/releases/Releases-941/progression 0ff69576f5814e0c9ba095e480db4f3f by mamadmin : Failed Assertion: Could not determine current phase
Octopus.Server.Communications.Lifecycles.FailedAssertionException: Failed Assertion: Could not determine current phase
at Octopus.Server.Communications.Lifecycles.LifecycleProgressionEvaluator.Evaluate(Boolean releaseHasUnresolvedDefect, IList1 deployments, List1 allEnvironments, Lifecycle lifecycle, IList1 tenants, String projectId) at Octopus.Server.Web.Api.Actions.ReleaseLifecycleProgressionAction.Execute() at Octopus.Server.Web.Infrastructure.Api.Responder1.Respond(TDescriptor options, NancyContext context)
at System.Dynamic.UpdateDelegates.UpdateAndExecute3[T0,T1,T2,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2)
at Octopus.Server.Web.Infrastructure.OctopusNancyModule.<>c__DisplayClass14_0.<get_Routes>b__1(Object x)
at Nancy.Routing.Route.<>c__DisplayClass4.b__3(Object parameters, CancellationToken context)
Task ID: ServerTasks-18046
Task status: Success
Task queued: Thursday, July 6, 2017 9:01 AM
Task started: Thursday, July 6, 2017 9:01 AM
Task duration: less than a second
Server version: 3.15.0+Branch.master.Sha.***********
Server node: *******
| Success: Check System Integrity
09:01:55 Info | Unexpected related document id format… [ Passed ]
09:01:55 Info | Schema… [ Passed ]
09:01:55 Info | Release channel belongs to the appropriate project… [ Passed ]
09:01:55 Info | Orphaned tenanted deployments… [ Passed ]
09:01:55 Info | Orphaned channels… [ Passed ]
09:01:55 Info | Only one unfrozen deployment process per project… [ Passed ]
I can add some more to this issue - I created a release for a lifecycle that has an optional TEST phase, then two further non-optional phases. After deploying this release to an environment in the optional phase, I tried to block the deployment of the release. This raised the Could not determine current phase error, and prevented the retention policies from completing with the same error.
I fixed this by making the TEST phase not optional, the retention policy then ran successfully. Putting it back to optional caused the retention to fail again. However, if I marked the release as not blocked, i.e. resolved, this also fixed the issue. So it appears you cannot block a release that has only progressed through the optional phase of a lifecycle. This is not good, because if we have discovered an issue with this release, we don’t want anyone else to deploy it anywhere.
Cheers, Simon.
