I have C# project in TFS + TeamCity (TC). Now i have tag 1.0, trunk 2.0 and TC build config for 2.0.
I need to enable build for 1.0 from tag (and for future tag 2.0, 3.0, etc..).
I've created common TC project MyProject with all necessary configurations. Now i added subproject '1.0 release brunch'. And i'm goning to copy all configurations from root project + change VCS roots of that configuration. When i'll have to make tag 2.0 i'll create subproject '2.0 release brunch' and copy all root configurations to this subproject and change VCS root.
Is this normal steps to support previous projects? Should i use configuration templates or something? Each project contains 5+ configurations to build CI and Full Release builds with all changes, E2E testing, etc. So this is not just copy configuration to the subproject and change VCS root. This seems will be a tuning for every project. And i'd like to automate this as much as possible.
One way of handling this situation is to create a single build configuration and use a parameter in the VCS trunk. So instead of using a VCS root of
https://server/svn/MyProject/trunk/
you would instead use
https://server/svn/MyProject/%TagPath%/
Then create a configuration parameter in the TeamCity build configuration called TagPath and simply set it's value to trunk or tags/1.0 or whatever.
The one caveat to be aware of no matter how you do this is that you will have problems if your build process changes in the future and in that case you would probably end up creating separate "old" and "new" build configurations.
You can use Build configuration template for this. You can create the template at the root project level and then use it for sub projects.
Look at the "Redefining settings inherited from template" section in the link below on how to use parameters to change the values at the sub-project level.
http://confluence.jetbrains.com/display/TCD8/Build+Configuration+Template
Related
I'm trying to ensure that my entire build configuration in Teamcity is under configuration management.
But, I'm also sharing a build template across different projects (with different VCS roots). The template is used in different sub-projects in Teamcity, where the VCS root is specified.
So, when I enable Versioned Settings for the project, only the specific settings are added, not the contents of the template. And as the template are defined in the root project, I can't enable Versioned Settings at this level.
Any suggestions?
BR
Rasmus
Create or move VCS-roots in Root Project or parent project,
if you change anything in above vcs-roots you can apply it to one or all configuration, there is an option in the last section of vcs-root setting looks like
On our TeamCity build server every project now specifies the deployment repository either using the command line argument -DaltDeploymentRepository or <distributionManagement> in the project's POM file.
However we are planning to move to Nexus 3, and there would be considerable amount of work to make sure that all projects are configured correctly. There is also the fact that the deployment procedure has to be communicated with every developer.
Is it possible to specify the Maven deployment target in settings.xml or other so that unless otherwise specified any project that does a deploy on TeamCity will get deployed to the correct repository?
...in settings.xml...no:
Servers
The repositories for download and deployment are defined by the repositories and distributionManagement elements of the POM.
...or other...yes:
Create a (or, if already existing, use the) parent POM from that all your projects inherit.
I figured out another solution: TeamCity meta-runner. By producing a working build you can extract a meta-runner which is kind of like a build-step macro.
If you first get the deployment working you can extract a meta-runner using Actions->Extract meta-runner... in the TeamCity build configuration.
This shows an editor for the XML that specifies the build-runner. Remove all the non-deployment specific build steps, and you can provide build step parameters in the meta-runner/settings/params block. You will probably need to add pomLocation and the specify %pomLocation% in the build step's <params> block.
I have several projects with dependencies between them and in the production build all the projects are packaged into jars, published and the main project simply adds dependency on these jar files.
During development and CI however I would like the main project to have dependencies on the related projects and build them too as part of the process (not compile, deploy and then build next, but rather compile all together).
This mans that in production I would have:
compile group:'com.me.aaa', name:'myCommonProj', version: '1.0.0'
while for the development builds I would like to have:
compile project(':myCommonProj')
Option #2 however requires the settings.gradle file.
How can I accomplish this setup?
I'd apply gitflow to the project and work in the following way:
in dev branch I'd keep compile(':myProject') dependency along with appropriate setting.gradle file.
in master branch I'd keep only fixed dependencies.
This scenario isn't very comfortable however because dev branch would be merged partially (fixed vs local dependencies), but it can be quite easily done. On the other side, working this way will prevent you from keeping strange logic in build script.
Second option is if it all un build.gradle and settings.gradle. CI server should expose build numbers and other environment variables. They can be used to include appropriate dependencies depending on environment.
I have a project called SPI with 15 configs. Those configs have dependency on a build config of project A.
I have been asked to run those same 15 SPI configs for project B and C. A, B and C are not dependent on each other. One way to do it is replicate the SPi project for B and C. But maintenance will be a nightmare. DO you have any suggestions on how to address this situation? DO you think I should use meta-runner? It will reduce the maintenance but not remove it. Any input is highly appreciated.
Which version of Teamcity are you using? Teamcity 8 has Build Configuration templates. I'm not sure when they were first introduced but if you have access to them, I'd recommend using them.
You can create build configuration templates from existing ones. So in your case, you can ask to create a build configuration template from each of the configs you have in project A. You can then modify those templates to make them generic and keep the customization specific to project A in project A itself. Then, base projects B and C's build configurations on the templates and simply customize the parts you need to in both those projects.
Here's more information: http://confluence.jetbrains.com/display/TCD8/Build+Configuration+Template
Build configuration templates is how we have set up our build system to build multiple branches of the same source code. When something must change, the changes are made to the templates which means they are automatically inherited by all projects that leverage said templates.
We have a Build that compiles and creates an artifact. Then we have another Build that uses the last Compile build and Deploys it to the proper environment. Once that is complete, I have to go and Tag the build in TC that it was pushed to the environment. Is there a way that I can tag the Compile Build that is was deployed using the Deploy Build?
I'm not aware of an easy way to do this (i.e. through a TeamCity configuration setting) but you probably could accomplish this using the REST API from your build script.
If you are using TeamCity 6 or above because you have a build dependency chain from the Deployment Build to the Main Build either through artifact dependencies, snapshot dependencies or both you can just tag your Deployment Build. This is because the UI will show you a tree view of the dependencies that the deployment used and you can navigate to the actual build.
One thing you can do, and in my opinion should do, is to tag your source control from TeamCity if you are using a source control that supports tagging/labelling. You should probably set your Deployment Build up with a snapshot dependency as well as the artifact dependency, especially if your build files are in the same repository. On your Main Build you should get TeamCity to label your repository on a successful build with something like "build-1.2.3.4". Then on your Deployment Build you should get it to label the repository after a successful build with "deployed-1.2.3.4". If you deploy to different environments then you can get it to label the repository accordingly.