We are building packages for multiple deployment environments using TeamCity server and OctoPack. The problem is that tentacle agent chooses the latest by number version of the package, so it's the same (latest) package that is deployed on all environments. Here's the summary of our setup:
Environments DEV and STAGE;
Deployment to DEV is triggered from Git "dev" branch;
Deployment to STAGE is triggered from Git "stage" branch;
OctoPack is configured to generate packages MyProduct.1.0.0.dev-%build_counter% for DEV build configuration;
OctoPack is configured to generated packages MyProduct.1.0.0.%build_counter% for STAGE build configuration;
TeamCity is configured to expose OctoPack artefacts (NuGet packages) via its NuGet feed;
Octopus project is configured to deploy packages with NuGet Id MyProduct from TeamCity NuGet feed.
So what happens is that since DEV builds are run more frequently, they have larger %build_counter%, and STAGE doesn't get a chance to get a deployment of its own packages - Octopus tentacle preferes packages with 1.0.0.dev-* suffix.
This must be fairly common scenario, but I haven't found a simple way to solve it.
There are some parts that are not documented here: https://github.com/OctopusDeploy/Octopus-Tools. But if you look at https://github.com/OctopusDeploy/Octopus-Tools/blob/master/source/OctopusTools/Commands/CreateReleaseCommand.cs it is possible to figure out what you can do.
I think the tools is backward compatible, but not 100 % sure about that.
When you are using the octo tools, which I expect that you use, you can set the version (also called releasenumber now) option to specify the release number. If you doesn't specify anything else it will take the latest package so what you want to do is set the packageversion (also called defaultpackageversion now) that should be used for the release.
I think that should do it. If it doesn't, what are you using to create the release?
Example of what we are using from our TeamCity when using octo tools which we have added to the environment path on the build agents:
create-release --server=%conf.OctoServerApi% --project=%conf.OctoProject% --version=%env.OctopusPackageVersion% --deployto=%conf.OctoDeployEnv% --packageversion=%env.OctoPackPackageVersion% --apiKey=%conf.OctoApiKey% --waitfordeployment %conf.OctoExtraParams%
UPDATE:
The documentation for 2.0 is much better: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596
Inspired by Tomas Jansson's answer, simply adding the following to Additional command line arguments in the OctopusDeploy: Create release build step (TeamCity v9) worked for me:
--packageversion=%build.number%
Related
I am starting to delve into Octopus Deploy and setting up my first deployment but I've ran into a bit of a snag. I have tried to be as specific as possible in lieu of finding someone who has experienced this same problem more recently. "This is not a new problem. See -reseach"
The setup
Versions:
TeamCity 10.0.4
Octopus Deploy 3.10.1
My continuous integration stack is comprised of TFS, TeamCity and now Octopus. My deployment process:
TeamCity runs the .NET application build. (Scripts, tests, etc..)
TeamCity Octopus plugin successfully creates the versioned Nuget packages.
A TeamCity build step using "OctopusDeploy: Push packages" pushes the packages to the octopus server.
In Octopus an external feed was added an tested called "Octopus Local Packages" pointing to the default internal octopus package directory: C:\Octopus\Packages.
An octopus project was created with a single step using the "Deploy an IIS Web Site" template, where the package section is setup like this:
The problem
Research
This has happened in the past on versions prior to 3.0.7 where it was fixed. Link to bug thread 1.
Then it started happening again at some point prior to version 3.4.15 where it was fixed. Link to bug thread 2.
Any help, fix, or workaround will be greatly appropriated. If there is a detail that I'm missing I will be more than happy to clarify.
Update
This may very well be a rookie mistake when it comes to Octopus. The error shown in the question is in fact a result of the deployment package not being found. The following are findings through documentation and trial an error:
Octopus Server (built in) is a push feed only. Meaning that packages can be uploaded to this feed but not consumed.
To consume Octopus' server local packages, namely the packages previously pushed to Octopus Server (built in) from say TeamCity, you have to serve those packages yourself.
You can server those packages through Octopus by creating an external feed that points to the server's package default path: C:\Octopus\Packages
Most Importanly, and the fix to the error!
When changes are made to a deployment process step, a new release MUST BE created. Simply redeploying the previous release will try to redeploy with the previous step settings saved in a snapshot and not with the new step settings. This may come a a surprise to TeamCity users like myself based on TeamCity's behaviour.
We're using Teamcity CI for build and Octopus Deploy for deployment.
We want to use Builtin Octopus deploy repository for storing Artifacts instead of teamcity repo. What are the differeneces between them?
Can you help me evaluate the built in Octopus repository. Pro/Cons, any complications you might be facing.
Thanks.
One of the key differences is that TeamCity can be used as an externally accessible NuGet server, but Octopus Deploy can't expose any packages it knows about. If you're building components in TeamCity that are exposed as NuGet packages and reused within applications then Octopus Deploy won't be able to handle that scenario.
If you're just building applications and exposing them for Octopus Deploy then my advice would be to push them to Octopus Deploy to manage, otherwise you end up duplicating on disk space as there'll be a copy of the package in TeamCity and a copy of the package in Octopus Deploy once it has downloaded it from the TeamCity NuGet feed.
Hope this helps.
The inbuilt Octopus Deploy repository allows you to automatically create and deploy a release as soon as it is packaged and published (usually during a server build). This is great if you want to schedule nightly builds so that your development/test/integration environment is always update to date.
External package repositories cannot be used to automatically create
releases, only the built-in package repository is supported.
It also maintains packages through a retention policy so you don't have to worry about running out of disk space.
We use two NuGet repositories. One for application packages deployed through Octopus Deploy, and one for shared packaged reusable components using NuGet.Server.
We use Octopus Deploy 3.2.16 to deploy a NuGet package to an Azure Cloud Service.
From our Deploy.ps1 file, we need to identify the newest NuGet package published in this feed.
For example, we have this scenario:
Day 1: we deploy v1.0.0
Day 2: we deploy v.1.0.1
Day 3: we re-deploy v1.0.0
When we re-deploying v1.0.0 on Day3, the Deploy.ps1 Powershell script that gets executed during deployment needs to identify the highest-version NuGet package in the current feed (I.E. "v1.0.1"), then retrieve and use a certain file from this package (I.E. "Library.dll")
Any suggestion on how can this be done?
I recommend handling this at the packaging level so the deployment of v1.0.0 with a different version of Library.dll is treated as a completely new release.
A critical part of deployment automation is knowing what is being deployed and dynamically chaning the dependencies will make your deployments highly volatile as the same version will not contain the same artefacts.
In most cases the adjusted package of v1.0.0 with the updated dependency would need to be tracked through the deployment pipeline just like any other release, whereas if you dynamically changed the artefacts, it could surprisingly have a different dependency on an environment just because a new version is flowing behind it.
We have a jenkins Job that package a WAR snapshot on every commit on SVN.
We also use the Release plugin that generate a versioned WAR on artifactory.
example:web:1.1-SNAPSHOT >> 1.1
We want include the deployment task on the jenkins work flow. On different project we also work with the promote plugin.
We are not sure which is the better approach for work with the automated deployment task, based on the number of future problems that we could found.
The first solution planned is :
Use the release plugin for generate a release stagging.
Use the promotion plugin for authorize the automated deployment.
This promotion launch a different job that download the last available WAR file from artifactory and deploy it.
We have discused if we can do it on the same "promotion action" or found a different solution.
Which solution is the most common for those cases? How we can restrict the accidental deployment of unauthorized versions?
Don't deploy the latest version, since you'll unintentionally deploy the wrong version, sooner or later. Use parameterized builds to deploy a particular version. The deploy-to-artifactory job sets the parameter and uses the parameterized trigger plugin to kick off all deploy-to-machine jobs.
You may want to parameterize all jobs in the pipeline after the deploy-to-artifactory job. I think there are other plugins that put the parameter into an entire pipeline, but I can't see them at the moment. There is a wide range of plugins that you can leverage in this workflow to suit your needs, such as the BuildResultTrigger plugin and the Build Flow plugin. And matrix builds are great for deploying to a range of machines, OSes, etc.
I've been researching this for a while but can't find an answer.
I use Bamboo 5.3 with Artifactory plugin 1.6.2. I have a build project that generates a .war and two .zips. I also have a Bamboo Deployment project that creates releases with these three files and deploys to DEV, QA and so on.
For a build project I am able to use the artifactory plugin, that's fine. The problem is that I end up with a lot of artifacts if I publish all the builds. I would like to publish to Artifactory only the files from the releases, so that is happens less often, and that the people would see only the 3-4 releases tries, not the 150 builds.
My issue is that when creating my Deployment tasks (like download, copy, call ssh script...) there is no 'Artifactory Generic Deploy', like in the build project tasks.
I see there is a new Bamboo 5.4 with some improvement around the deployment process, maybe this could help?
Support for deployment task from Bamboo to Artifactory will be available starting with version 1.8.0 of the Artifactory plugin.
Here is the Jira issue.
I faced a similar issue. Hopefully the next release of the artifactory plugin will integrate with deployment projects.
If you are willing to use Maven to broker the deployment, deploy-file can get the job done.
In the deployment project, after your artifact download task add a Maven 3.x task for each artifact you want to send.
You'll need to specify a build JDK and for environment variables I'm using MAVEN_OPTS="-DskipTests=true -XX:MaxPermSize=4096m"
For the actual maven command:
deploy:deploy-file
-Durl=http://${bamboo.artifactory_username}:${bamboo.artifactory_password}#${bamboo.artifactory_url}/artifactory/${bamboo.destinationRepo}
-DrepositoryId=localhost
-Dfile=${bamboo.pathToArtifact}/${bamboo.arftifactName}-${bamboo.majorVersion}.${bamboo.minorVersion}.${bamboo.arftifactExtension}
-DgroupId=${bamboo.arftifactGroup}
-DartifactId=${bamboo.arftifactName}
-Dversion=${bamboo.majorVersion}.${bamboo.minorVersion}
-Dpackaging=${bamboo.arftifactExtension}
-DgeneratePom=true
Hope this helps!
The artifactory API is pretty usable for this purpose. You can deploy directly using curl in a shell script.
See https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API for the details.