Teamcity 10 offers new feature storing project settings in version control
What is the best practice to follow in terms of storing these settings?
Keep it in the same repo where code resides?
Put it into separate repo?
We have put it into separate Git repository called teamcity-settings after having it in repository with some other stuff for continuous integration. The problem with having it together with something else was that it makes too much "noise" in git history, since every TeamCity build configuration update is doing a commit.
So my suggestion - let TeamCity settings live it's own life in version control. :)
Related
TeamCity appears to store the definitions for builds, projects, templates etc as XML internally.
This is exposed in the "Administration > Audit" view where you can see diffs that people made to individual configurations, at URLs like http://teamcityserver/admin/settingsDiffView.html?id=project:project10&versionBefore=8&versionAfter=9&actionId=3151
I'd like to manage a TeamCity setup partially from outside the web interface - e.g. for example keep the build definitions in version control and perhaps programmatically generate them.
Is there any way I can directly upload definitions in this format (or any similar alternative)? I'm aware that there are various APIs and extension points to TeamCity but haven't managed to find any that gives direct access to anything like this.
I can live with the format changing with TeamCity versions if necessary - it would be a reasonable price to pay for the other benefits.
For TeamCity 9.x and newer
As reported by Ganesh in the comments to this answer, an option was added in 9.x that supports changes and versioning through Source Code Management (SCM) tools. Please see his answer for 9.x and beyond.
For TeamCity 8.x and older
It might not be the "approved" way, but you can edit the project files on disk, and those changes will appear in your build configs. I have successfully edited them outside of the Web UI after they were created.
So, you could probably open that folder up as a restricted network share or set up ssh.
You'll find it at $TeamCityData/config/projects/ and then they are stored in subfolders such as $projectName/buildTypes/$buildFile.xml
An example is:
E:\TeamCityData\config\projects\CSandbox\buildTypes\CSandbox_Project1TrunkBuildUnitTest.xml
TeamCity 9 adds a new "Versioned Settings" feature which keeps these XML files under version control and allows changes to be made via the VCS.
In TeamCity 9.0 this can be git or mercurial, and the upcoming TeamCity 9.1 will add support for Perforce and Subversion.
I've been using it with git for a few months and it works quite nicely in practice.
I sometimes have trouble persuading TeamCity to notice changes coming in from the VCS - particularly when deleting projects - but otherwise it's been really useful for standardising configuration and spinning up new job chains quickly.
Another slight annoyance is that you can't configure the location within the repository that the settings come from - it's always .teamcity in the root - so I've had to use multiple branches or repositories to manage multiple TeamCity servers.
We'd like to implement CI using TeamCity.
We use Git for source control and would like to make use of the "pre tested commits" or "personal builds" feature of TeamCity.
Does anyone have experience with the VS plugin for Teamcity?
As far as I've seen, it only supports Subversion, no word about Git.
Anyone used this setup with any success?
As explained in Pre-tested “Commits” using Git by JoergM, you can emulate a solution similar to the TeamCity6.x "Personal builds on branches", by using personal repos:
.
There is one central Git-repository that only contains pre-tested changes. I call this “Green Repository” because it should only contain changes that lead to green builds.
Every developer pulls from this repository but nobody is allowed to push to it.
Instead everybody has a personal repository (think fork if you were on GitHub). The CI Server watches those personal repositories. After a commit it starts the compile and test. If that was successful it pushes the changes to the Green Repository.
JoergM adds:
The question is whether we will continue using our own solution or switch to the new feature of Teamcity.
So far I can’t see any advantage of the Teamcity feature.
With our solution we are even more flexible in regard of branch design.
This kind of setup is similar to what I described in "What is the cleverest use of source repository that you have ever seen?".
TeamCity 6.5 has new feature: remote run on a branch. It works for Git and Mercurial and does not require IDE, see more here: http://confluence.jetbrains.net/display/TCD65/Branch+Remote+Run+Trigger
Note that support for Git branches has been considerably improved in TeamCity 7.1. In my opinion, this is far better than the personal build feature.
The relevant docs are available here: http://confluence.jetbrains.net/display/TCD7/Working+with+Feature+Branches
I am a complete noob to this so if there is a completely obvious answer by all means make fun and point and laugh then give the answer.
We use Visual Studio 2010 to compile our published website. I have a repository that I use for my source code and one which I publish the compiled code to. I then check out the publish repository on the testing server and once it tests good I check out the repository on my main server. This is fine and all but I am using Tortoise SVN and automating the commit. Problem is, I really need to wipe the publish SVN repository, then copy the files, then commit. I just can't get that to happen and have it still recognize it as a SVN repository. Suggestions?
First of all, don't put compiled code into your source repository. It's bad form.
Look at Jenkins as a build server. Jenkins can use the msbuild.exe command to build .NET projects using the .sln file your project creates.
When you do a commit in Subversion, Jenkins will automatically fire off the build. If you have NUnit tests, Jenkins will run those and give you the results. You can have Jenkins store the compiled files for you in its archive. If someone wants to install a particular build, they can directly download it from Jenkins without having to do a checkout in Subversion first.
Jenkins offer all of these advantages:
It shows you all the changes in your repository and what changed in each commit.
It can run all sorts of tests automatically for you.
You can mark builds that are released using the "Simple Promotion" plugin.
You can tag builds in Subversion directly in Jenkins without needing a command line or working directory.
It can alert the developers if a build fails due to bad code, or if testing fails. These alerts can be done via Email, instant messaging, phone text messages, Twitter, and many other ways. All it takes is the right plugin which Jenkins makes easy to install.
Jenkins can act as a release repository which makes it easy to find the release, what's in the release and why.
Jenkins integrates with Bamboo, ViewVC, and Sventon. These are web-based repository browsers. This way Jenkins not only shows you the file changed, but what changed in the file.
Jenkins is easy to use and install. Download it and give it a try.
Unless you have a hard and fast requirement which forces you to use two separate repositories, i'd suggest taking a look at SVN tagging and branching functionality.
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-branchtag.html
Having a repository for the published code really doesn't buy you anything. IMO, you would be better off with a bunch of zip files (one per release) with the date and SVN branch reflected in the name. DO have a changelog .txt file in the zip, and also check that into the repo.
Problem is, I really need to wipe the publish SVN repository, then copy the files, then commit.
You don't need wiping in repo. Just make commit to production repo with exported HEAD from dev-repo (post-commit hook for commit message)
And tags, yes, are more natural and bulletproof way.
In my CruiseControl instances, I have version controlled the ccnet.config file.
When I want to update CruiseControl, I run an "update config" job which fetches the config from version control.
In this manner, the very build process of a release is configuration managed.
I am wondering how to achieve these goals effectively under TeamCity.
I try to keep what ever CI I am using as light as possible and put as much of the running of the build into an msbuild or nant script including running tests, code coverage, etc.
The benefit of this is:
The build file is version controlled.
You can run the script in any environment.
Easier to move between CI environments.
Everyone becomes responsible for the build.
This has been introduced in TeamCity 9. Also answered in another post:
Version control (e.g. in TFS) build configuration for TeamCity - is it possible?
I've been wanting a way to source control TeamCity config for a long time. I ended up writing a Windows Service which monitors the configuration directory and commits changes to git.
The project is on GitHub: https://github.com/grenade/teamcity-config-monitor
You might try looking at the folders that are backed up prior to upgrade (or when restoring team city) as those represent the configurations and changes you've made since initial installation.
http://confluence.jetbrains.net/display/TCD4/TeamCity+Data+Backup
Some of the relevant data is actually a database, (and in fact the documentation advises you to point team city to a real database like mysql instead of the default embedded database it uses)
You could try checking those into SVN, but you'll want to stop team city for any check-in actions.
We have a continuous integration server with over 40 jobs that are constantly changing. I would like to version control continuous integration build jobs in Hudson so we can roll back changes if we have problems.
Is there a Hudson plugin that will do this or other solution that already exists or should I keep the config.xml files in SVN.
Hudson Labs has a really great write up on this, Keeping your configuration and data in Subversion
This is the first bit of the article
We all know that keeping important
files in version control is critical,
as it ensures problematic changes can
be reverted and can serve as a backup
mechanism as well. Code and resources
are often kept in version control, but
it can be easy to forget your
continuous integration (CI) server
itself! If a disk were to die or fall
victim to a misplaced rm -rf, you
could lose all the history and
configuration associated with the jobs
your CI server manages.
It’s pretty simple to create a
repository, but it isn’t obvious which
parts of your $HUDSON_HOME you’ll want
to backup. You’ll also want to have
some automation so new projects get
added to the repository, and deleted
ones get removed. Luckily we have a
great tool to handle this: Hudson!
We have a Hudson job which runs
nightly, performs the appropriate SVN
commands, and checks in
You only seem to be interested in the configuration, which is fine, just ignore or filter out the bits about the data and focus on the configuration.
This is one of the more recent threads about using version control with Hudson's configuration on the Hudson users list.
There are no plugins to do store configuration in an SCM right now (March 2010) though the backup plugin might do something close to what you want, but perhaps with less of a view of 'change' and more of just a snapshot at any given time.
The relatively new Job Config History plugin gets part of the way there - it doesn't actually store the configurations in source control, but it does provide history and auditing of changes to jobs.
You could look into the SCM Sync configuration plugin.
It automatically commits all of your jenkins config changes to svn. that way you can track configuration errors easily.
https://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin