We use TeamCity and Subversion for build management.
For each project, we have multiple build configurations, one for each environment we will deploy to (e.g. Dev, Test, Staging).
It makes sense, I think, to use a TeamCity Template to keep these configurations in sync, overriding the differences with parameters and variables (e.g. overriding NAnt targets).
The problem is that I cannot override the VCS Labelling configurations (the options are greyed out in the build configuration attached to a template). Ideally I'd like only the builds going to Test and Staging to be tagged, not the Dev builds.
Is there a way I can achieve this, or am I going to have to abandon the Template idea and have multiple build configurations?
I'm using TeamCity 6.0.
I'm afraid this is not implemented yet. You should probably vote for http://youtrack.jetbrains.net/issue/TW-15182 request.
Related
We have set of different web application projects, which is delivered by Teamcity to different environments. At this moment, we are doing all-in-one builds: compile, package and deploy at once; all based on a templates.
Now I am investigating a way to separate concenrs: one build tests and produces package, another - delivers. Naturally, both builds are having own templates. Is there a way to template this build chain - so, when I choose some meta-template - both builds will be created with present Artifact dependencies?
Sadly not. What we've had to do is clone the build chains. We've put in place a mechanism which makes sure the set-ups of the different chains do not diverge.
Another option, admittedly ugly, is to set up a single build chain and let each of your projects pretend that it's a separate VCS branch. In this case there's a single set-up (for the single build chain) and to view the history of a given project you filter by that project "branch". Needless to say, that's not how branches should be used and you may run into some issue down the line.
I have been working with TeamCity, Jenkins and Bamboo my last 8years. Latest 2years very involved in ContinuousIntegration factory setup and mainteinance on my team with very good results, giving me a lot of habits about how to deal with builds, artifacts and pipelines.
Now, i'm on a new company, new team, new CI, TFS2015, first time for me.
Just one month before I arrive to this new team they were on TFS2012, with XAMLs, so I took the migration to vNext builds.
At first look, I found on vNext builds the classic build definition, i mean adding steps as a single task to the build, instead of monolithic XAML file.
But with the time, i was trying to create more complex builds, like TeamCity build chains, but this is not possible, strike one...
Then, I was trying to deal with multiple branches, one continuous build for each branch (we are on TFSVC), create packages from each branch, and I found I was duplicating my builds just to change repository paths and a few details, so I moved builds to templates trying to reuse build definitions, introducing variables to generates paths(for repos and branches) and versions and expecting to change only in one place the build and having this changes reflected in all builds derived from templates... but that's was not the case... :
variables are not accepted everywhere, like in repo paths.
can't change templates after created them, just replace them, and builds created from templates are not affected after template is changed.
strike two ?.....
I'm wondering if maybe I'm doing things wrong with TFS, maybe this is a different system and I can't do things like in other CIs.
Any advice in how to approach TFS to have a good, dynamic and reusable set of builds ??
here isn’t the feature that the changes of a build definition or template affects other existing build definitions.
If the build steps of build definitions are the same for each branch, you just need a build definition and add filters for each branch (Triggers > Continuous integrations (CI), after that it will uses corresponding source to build for CI build, for example, develop branch changes > Trigger a build automatically with develop branch source.
On the other hand, you can change branch and source version when queue build manually or through REST API.
If the build steps are different for each branch, you need to modify the definitions independently for detail requirements.
Q. How can I setup our config/transforms to get release management to work in the example way?
I'm trying to get release management to work in the way all the videos seem to show. The same build progressing through environments going through build --> Dev/Staging --> Production.
It's making me step back a little and question the way we do our configurations in Visual Studio solutions (and our git flow branch process). I think the way we use the configurations is making things more difficult further down the line with the build and then release.
Configurations
We currently use the two default configurations, debug & release.
We tend to use the debug build on our Dev (contains the dev database
connection string & other app settings transforms). This is what we deploy to 'dev'.
Then we also have the release configuration with the production transforms in. This is what we deploy to 'Production'.
How can I setup our config/transforms to get release management to work in the example way?
One option: Build both configurations. Publish both configurations as artifacts in your build.
In your release definition, deploy the appropriate configuration from the linked artifacts.
Another option: Don't do compile-time configuration transforms and instead do deployment-time configuration.
What you provide in the screenshot is a Overview of releases. Which is used to track a release in Microsoft Release Management. Based on a release name and links.
The Overview page shows a list of release definitions. Each one is shown as a series of environments, with the name of the release and the date or time it was started. The color of the heading and the icon in each environment indicate the current status of the release. The color scheme is the same as in the Releases page.
You just need to follow the provided starter deployment templates or you can also create your own templates for your project.
Back to the screenshot, there are just the environments in a release build definition. You can add the need environment in the definitions.
After that you will view the same thing in the overview just like the example:
For your situation, you can created two separate release definition with two build definition based on the both configurations. Moreover,there has been a very detailed document in MSDN, including setup, configurations, manage release, deploy, you can have a systematic understanding.
Is there a way to have a whole project including all build configurations in a template?
We have a setup where we deploy several applications using TeamCity and the only difference in each deployment is the VCS root. The build process is the same for each of the applications.
What I have been looking for is a way to have a template for the build configuration so that new applications can easily create the TeamCity project from a template instead of the quickest way we have ATM which is the copy an existing project and change the VCS root.
Any other ideas on this, or thoughts on other ways to approach this would be welcome.
I have a similar situation, and have found that templates are the way to go. I have a template for the build, and include a parameter for the git repo. Then, in the template, add a VCS root with the address set to the parameter. Works like a charm.
What we use:
We use mercurial and bitbucket for repositories. Appveyor and kudu for continous integration and deployment. We are using visual studio 2015 as IDE.
What we have:
We have different web projects. They share some other projects. All of web projects have their own solution. Every solution have their own repository.
If there is change on develop branch. Appveyor builds this repository, tests and deploys it.
If there is change on default, kudu builds this repository and deploys it.
What we want:
We want to merge all of these projects in one solution. But I couldn't figure it out, how I can achive continous integration or deployment.
If I change something on webproject1, I just want to build and deploy webproject1. The other webprojects in solution neither should be built nor deployed.
Perhaps a single repository will help you. Using relative path to include the shared libraries from your different applications.
Each application can still have its own Solution file and your CI setup also stays as it is. What changes is that the shared projects you have across all applications will be referenced with relative path. E.g.:
Repository root\Core\Component1\Component1.csproj
Repository root\Core\Component2\Component2.csproj
Repository root\Applications\App1\App1.sln
Repository root\Applications\App1\Domain\Domain.csproj
Repository root\Applications\App1\Web\Web.csproj
Repository root\Applications\App2\App2.sln
Repository root\Applications\App2\Domain\Domain.csproj
Repository root\Applications\App2\Web\Web.csproj
Now your different application can include the Core\Components they need by adding existing project to solution using relative path.
Your continuous integration system will have VCS triggers watching the app and dependencies so only relevant changes fire a build.
So if App1 developer makes a change on Component1, and Component1 is also used by App2, the build server will trigger a build to App1 and App2, signaling any breaking changes. However if App2 doesn't not depend on Component1, then only App1 will build.
This is achieved by configuring the build triggers for your applications.
One benefit of this strategy vs having a single .sln is that you won't have to build everything each time you build solution (nor configure what projects to build each time you work on a different app)
Also note that you can achieve this with multiple repositories. But that means you'd need to check them out at the correct location so your relative paths work. It's also quite obscure since if you checkout App1 and try to build it. It simply won't work and you'll have to figure out which other repos to check out, etc.
You are using Mercurial but FYI, the way (one of) this would be handled with Git is with submodules.