I'm just getting to grips with TeamCity and MSDeploy and have deployment to a dev environment triggered by SVN commit working nicely. The question I have is in terms of releasing to a test environment; I want to do this on demand and based on a specific revision number. What's the best way to configure a TeamCity build based on a user-defined revision?
You can use Run Custom Build Dialog in the TeamCity, and customize there Changes to include parameter, where you need to specify actually SVN revision to build.
Take a look on Pin functionality in TeamCity. You can pin a certain build and then deploy latest pinned build.
So you have a 'Create development build' task in TeamCity which deploys to dev environment and exposes artefacts. You can create another task in TeamCity that will use artefacts from latest pinned build in 'Create development build' task and deploy to your testing environment.
You can create yet another task that deploys to production latest pinned 'test' build. Rollback can be achieved by simply unpinning last pinned build.
You also have a history of deployed build.
Related
I am using Bamboo 5.6.2 version.
I have a requirement to create a release every time a build is successful as part of Continuous Integration Pipeline. Output of build pipeline is a link to docker image from an external docker registry.
Reason being: Administrator has configured build expiry where old build results may be deleted including artifacts.
Intent: Creating a release will ensure that build result/artifact stays and thereby allowing us to deploy it at a later stage by referring to artifact.
I found similar question here: https://answers.atlassian.com/questions/33136376/how-can-i-automatically-create-a-deployment-release-but-dont-execute-deployment-yet but yet to be answered.
Create Deployment environment with echo script task and add trigger to that environment to deploy on successful build. Not sure such trigger exists in 5.6, working with 5.14.4
I'm a bit confused around msbuild and nuget tools in order to integrate them in a continous delivery line.
I've set up my CI server (jenkins) and my NuGet reporsitory (myget)
Mainly, I need to hook several points inside the CI process:
On developer machine: Do nothing, simply build and generate artifacts locally.
On CI Server: Pushed commit on develop, feature\*, hotfix\* like branches.
When a commit is pushed on whichever of the above branches I would like to:
Push the artifact on NuGet repository.
How could I get it using two single msbuild scripts?
We're currently using TeamCity Enterprise 9.0 for our continuous deployment process; so please imagine the following scenario, you deploy your latest code to the dev branch, but one of the nugget packages was removed from the source and the build fails, QA team comes in at night and finds the build is broken and the environment is down for testing.
So I was wondering if there is a way to configure TeamCity to automatically run the last successful build in case the current code version fails, like configure it to make it aware that the current branch is broken and thus go back to a previous stable state.
Thanks,
The recommended approach is to have a separate build configuration for Deployment task. In this case you will be able to configure artifact dependency with option get artifacts from "Latest successful build".
Also see how to set up deployment with TeamCity.
I'm evaluating Bamboo to replace our Jenkins setup and have a couple questions. I have a .NET solution that generates two artifacts: a packaged website and an MSI. I have three environments I deploy to: test, stage, production. Our Jenkins server in turn has three jobs--one for each environment. Each job builds the solution, copies in configuration files for the environment it will be deployed to and then deploys the artifacts. Reading the documentation and other stuff (https://answers.atlassian.com/questions/19562/plans-stages-jobs-best-practices), I'm getting mixed signals about how deployment should work with Bamboo. It seems to me like deployment plans expect artifacts to exist and then deploy them. But, build plans include deployment steps as well. How is all of this supposed to interact together?
The reason I'm confused is because I have environment specific configuration files that get packaged during a build. Any direction on how this should work?
I posted the question to the Atlassian board as well and got an answer I think I like the best:
Jason Monsorno · 762 karma · Aug 30 '13 at 04:38 PM
Deployment projects in Bamboo seem to be dependant on the existance of
an artifact, the catch is you don't necessary need to use that
artifact so you could use an empty artifact and do completely
independent steps. Deployment projects are still fairly new to Bamboo
and your structure may favor the "normal" workflow so each environment
would be a separate manual stage.
The Deployment project do have a separate workflow and versioning. To
use Deployment projects in your scenario, I'd suggest making the
artifact the entire checkout then each Deployment environment can
build a copy of the artifact. The space-saving/less-time-efficient
option would be to just save the current revision in a file as the
artifact and use that to check it out and build in each Deployment
environment.
I am testing out automatic deployment of build artifacts from Bamboo to Artifactory. I installed the Artifactory plugin in Bamboo, and then set up a test build plan. I added an "Artifactory Generic Deploy Task" since I'm not using Maven, Ivy, or Gradle.
My repository layout is:
group / product / version / filename.extension
It was pretty easy to specify where the artifact should go in the "Edit Published Artifacts" field in Bamboo:
myartifact=>com.example/someproduct/${bamboo.buildNumber}
This is fine for snapshot builds, but what if I want to make a release with a specific version number? What do I put in place of ${bamboo.buildNumber}? Or do I need to take an entirely different approach?
It's normally preferred to promote a satisfactory snapshot build to a released status than to run an independent release build.
Although Artifactory's release promotion support was not implemented for Bamboo's generic build type, starting with version 2.6.0 you can actually implement your own build promotion strategy within Artifactory as a custom User Plugin and invoke the procedure via a REST-API command.
So the procedure becomes pretty simple:
Write a release promotion strategy.
Add a Bamboo build step that executes the promotion via REST.
Build your snapshots until you're satisfied with the state.
Execute release step.
We also keep an example of a release promotion strategy plugin in github.