I'm looking at using TeamCity 7.1 as our build server, and I am trying to figure out if it is possible to do what I want.
Our TFS branching looks like this
MyProject
tags
1.0.0.0
1.1.0.0
2.0.0.0
trunk
So our process is to work in the trunk, and when we reach a point where we want to deploy, then we create a branch with that code. In the above example, version 2.0.0.0 is in production, and the trunk has further changes made to it. So if I need to fix a bug in production, then I will fix it in the 2.0.0.0 branch.
I am able to set up a build that checks out the trunk, runs tests, etc., without any problems, and it can be triggered by checkins to the trunk. But I would like to also monitor all the version specific branches, so that when I check in a bugfix in the 2.0.0.0 branch, then a build is triggered, and all my tests are run.
It seems that some of the VCS options have had a new feature added to support this called "branch specification" (https://tom.cabanski.com/2012/11/19/teamcity-7-1-branch-builds-rock/) but that is not available on a TFS VCS root.
Is it possible to do this without creating a separate build configuration for each of my version branches? Or is there a way to manually launch a build of a specific branch, by using my existing build configuration for the trunk?
Since "feature branches" are not supported for TFS in TeamCity (only for Git and Mercurial at this time), creating separate build configurations is the best way to build separate branches. Actually, even for Git and Mercurial creating separate build configurations for long-lived version branches (as opposed to feature branches which come and go) is recommended.
I am not sure how branches are handled in TFS, but if you use tags, I believe there is no way to build off a TFS tag in TeamCity (TW-7370).
Related
I'm trying to deploy a Continuous Integration server where I work.
We used TFVC with the branch to release strategy, but we are having difficulty with something that should be trivial.
We only need the build on the branch that was checked in.
Is it possible to do this without having to change the build definition every time a new branch is created?
I do not want to map the entire folder structure of the repository. Imagine having 10 branches and every check-in, build all? Does not make sense!
Anyone have any idea how to do it?
The CI build for TFVC can’t map and just build target branch like build for Git.
There are some workarounds:
Clone a build definition and change source mapping, Path filters of triggers for each branch.
Add a PowerShell step/task to get recent check-in change by calling get changesets Rest API, then store the related solution/project files in a variable by using Logging Commands, then build these solutions/projects
I'm currently setting up continuous integration using TFS/Visual Studio Team Services (was VS Online), and I'm using the Team Foundation Build 2015 tasks. So not the XAML builds.
I'm using it to build a Xamarin Android project, but that's pretty irreverent I guess,
The process should be like this:
After a check-in:
TFS should download the sources
TFS should increment the version number within AndroidManifest.xml
I've managed to do this by making a PowerShell script for this.
After the AndroidManifest.xml file is modified, it should be committed back into the TFS repository
Then the rest, build deploy into hockeyapp etc
The first steps are all configured, but I'm struggling with the commit part. How do I get TFS to commit the file? I don't really see any task suitable for it. I've tried using the Copy and Publish Build Artifacts Utility - But that did not seem to work, and I'm not even sure if that's the right utility
I'm using the default hosted build agent btw. Any help would be appreciated
Warning
I do want to point out that checking in changes as part of the build can lead to some features of VSTS/TFS not working. Association of work items to the checkin, sources and symbol generation, tractability from changes to build to release and integration with Test Manager, remote debugging, will likely not yield the expected results because the Changeset/commit recorded in te build may not match the actual sources. This may lead to unexpected funny behavior.
Also, if any new changes have already been committed/checked-in after the build has started, the version number may be updated in Source Control for code that was not actually released under that version.
So: First of all, it's considered a bad practice to change the sources from the build process.
Alternatives
There are better ways of doing it, one is to use the build version (Build_BuildNumber or Build_BuildID variables). Alternatively you an use a task like GitVersion to generate the semantic version based on the branch and tag in your git repository. That way your build will generate the correct version number and will increment the revision in case the same sources are built multiple times.
I understand, but I still want to check in my code as part of the build
If these things don't work for you and you still want to check in the changes as part of the build, you can either use the TFVC Build Tasks if you're using TFVC or use the Git Build Tools to add the remote to the local repository and then use the git commandline tools to commit and push the changes back to the repository.
These extensions require TFS Update 2 to install. But you can push the individual build tasks using the tfx commandlien tool. For the TFVC tasks the process is explained here.
On mac
On the mac it's going to be harder since you're using TFVC. My TFVC tasks leverage the TFS Client Object Model and Powershell to communicate to the TFS Server. The tf.exe tool doesn't even work on windows when you're in the context of a build, which is why I need to call into the VersionControlServer object directly. Given I'm dependent on these technologies, the tasks won't run on a Mac or Linux agent.
You could try to see whether the Team explorer Everywhere X-platform commandline works from the build agent (using a shell script). I have no way to test this on an actual Mac.
Given the cross platform nature of your project I'd recommend to move to Git, it integrates into XCode and Android Studio, making it easier to do a native UI or build on top of native libraries.
Alternative 2
You could setup a build which does the required changes to the code and then checks in the modified code. Then have a (CI) build run the Android and the Mac builds using the modified code.
At the moment, from what I know, if you have two branches, you have to have both branches mapped to locations on your machine and Visual Studio (or TFS within Visual Studio) will download the latest version and merge the changes locally and then you have to check in the other branch. I would like to be able to merge this branch with this branch with only having one branch mapped locally?
The purpose of this is that we have a development branch, a test branch and a release branch and we are merging changes from the development branch into the test branch and building it on the server which is then deploying it on another server. All this is working great but the test (and release) branch must be mapped on the machine of anyone trying to do this otherwise it won't work.
Ideally I'd like to be able to log into Visual Studio Online and do all the merges, builds and deployments there rather than on my development machine at all - is any of this possible? And if so, how please?
Not entirely sure this is something support-able by the TFS product, actually. Merges tend to need at least a minimal amount of human interaction whenever there is conflicts (and even in the cleanest merge relationships conflicts can and do arise).
However, you can do this on the build machines if you wish by performing the merge just before the build occurs and if the build succeeds, checking the merged changeset in.
Using the Pre- and Post- build script functionality in TFS build, you could try to do something such as the following...
Pre-build script would include commands such as:
tf merge $/ProjectRoot/Branches/Dev $/ProjectRoot/Branches/Test
tf resolve $/ProjectRoot/Branches/Test /r /i /auto:TakeTheirs
Post-build script would include:
tf checkin $/ProjectRoot/Branches/Test /r /i /comment:"***NO_CI*** [AutoMerge]"
We are using TFS2010 for source control and TeamCity 8.x for CI. In our project we have Main branch for releases and bug-fixes and Dev for most of the development. Build steps for both branches are identical. and we have a few build configurations to go through:
I can't seem to make TeamCity to do checkout on a single branch and run build only on the branch that was checked-in to.
First attempt: I've added a VCS Root to point to $/Root that contains both Main and Dev branches and created checkout rules:
First checkin to Main works fine. Checkin to Dev after fails like this:
where DoNotExportAttribute is the file that was modified in the Dev branch. Even if I have
checkbox against "Clean all files in the checkout directory before the build".
My second attempt was to add both of the branches as VCS roots:
But this caused checkout of both branches into the same directory and whatever was checkout first was overwritten by second branch.
Is there a remedy for our case without creating separate configurations for every branch? (we started from config-per-branch, but that proven to be maintenance heavy for the number of steps we do in build)
If I understand correctly, you're trying to use a single TeamCity project for both your main and your branch builds. I would not recommend doing that. By re-using the same project for both your main and your branch builds, you will be sharing version numbers between two different beasts. Version 1.1.4 of the build might be a main build while version 1.1.5 might be a branch build.
By looking at the artifacts created by the build, it will also be difficult to identify which source code was the one selected and included into that artifact. Is the executable a main or a branch executable?
The way we solved the main vs branch problem was by creating a "template" project which contains all our build configurations (each one set up as a Build Configuration Template so they can all be changed in a single location) for building our software. Both the main line and the branch projects are created by copying this "template" project and setting the VCS root to the appropriate directory location.
We run five build agents and each build takes a fair amount of time. Having individual projects for each branch allows us to run builds in parallel if the main and any of the branches happen to have been modified at the same time whereas with one single project, the builds would be done serially.
Hope this helps.
I use TFS with Jira to managment my team tasks.
I want to integrate a Code Review tool at development process.
When i try to use crucible i reveal that it not support TFS.
I want to know if , there is a good and credible solution for this ,to enable me use crucible with TFS.
additional , if there are another suggests for code reiview tool for VS and JIRA.
Thank!
Some time ago we decided to run Crucible on our project. Our project uses TFS 2012. We use one branch in TFS called 'dev' as a trunk, i.e. branch where developers make commits and where raw code located. Second branch where release code located called 'main'
Our workflow for peer review was:
Make some changes and shelve code
Send email to reviewer
Reviewer doing review in some custom tool and send email with notification that he is done
Commit code into 'dev' branch on TFS
Wait while build-server makes successful build
Commit to 'main' branch where production code resides
Our goal was to improve step 2 and 3. Crucible is great tool, but it doesn't support TFS out of the box, thus we decided to use some TFS bridge. Actually, there are two main options either using tfs->svn or tfs->git. Finally, we decided to use tfs->git bridge, because creating branches in git extremely cheap and it might have been helpful (it did), because we was thinking use branches in git for out shelvesets in TFS. Finally we made our mind to use git.
So far I know only 2 options to convert TFS into git:
git tf - this one works on Linux and recommended by Microsoft
git tfs - this one works only under Windows, but we choose this one, because of large set of commands
We need to convert TFS branch into Git repo and maintain our git repository in fresh state. We don't work with git to push new changes back into TFS, we need git repo only for Crucible.
There are steps we made to achieve the goal:
1. Firstly, we cloned our TFS "dev" branch into "dev" repo. We needed only this one branch, and we haven't any back merges from "main" branch. We have tried to do this with clone command, but without any luck:
git tfs clone http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
This command cloning full history from TFS, but it seems our TFS branch quite large and at some time git-tfs crashed with System.OutOfMemoryException exception. Another time, we failed with exception that max limit of path was exceeded, we found workaround by mapping workspace dir into as short path as possible as follows:
git config --global git-tfs.workspace-dir e:\ws
When we failed with clone command, we went to use quick-clone command. This one cloning starting from any time in history, from any changeset.
git tfs quick-clone -c545532 http://tfs:8080/tfs/DefaultCollection $/SOME_PATH/dev
Option -c545532 here is the number of changeset to starting copying from. Once per year we update all our source files with new header, thus we just to copy from beginning of current year. In that way we should have all necessary history to make branches from shelvesets.
If you hadn't used -c argument here, you would have haven't any history at all, because quick-clone copies just history if you asking for it.
Once repository was cloned, we had written "script" and put it into task scheduler to run every 5 min. What script is doing is just checking for new commits in TFS and creates new branches on our git repository. Again, we use git-tfs here. To get all new commits we call pull command:
git tfs pull
To unshelve TFS shelveset into particular git branch we use unshelve command:
git tfs unshelve -user=TFSDOMAIN\Username "Shelveset Name Here" Branch_Shelveset_Name_Here
This last command creates branch 'Branch_Shelveset_Name_Here' in git from shelveset 'Shelveset Name Here' in TFS. A shelveset's name can contains spaces and some escape chars, so our "script" clean up such cases. As I said, creating branches very cheap on git, thus we haven't any problems with this. If something was pushed into git repo we call crucible API to refresh it.
BTW: To make git repo visible in network I just installed SCM-Server. Crucible was installed and configured to use our domain username/password, thus we get email notification as well. As result we drastically improved step 2 and 3 from our workflow and it works for few months and we are happy with it.
Our workflow became:
Make some changes and shelve code
Wait for our shelveset in crucible (about 6-8 min), create review
Reviewer doing review in crucible
Commit code into 'dev' branch on TFS
Wait while build-server makes successful build
Commit to 'main' branch where production code resides
While working with this I noticed few issues:
Issue1: If you added new file into project and shelved it, you would not see it in git repo, because git-tfs can't find parent commit for it. I'm not sure is it bug of this tool or not, but simplest workaround for this, is having at least one file in shelveset with existing parent. For example, you have added 2 new files and want to send it for review. Instead of creating shelveset with these files, just touch any file which already in git repo (make it pending in Visual Studio), finally you will be able create shelveset with three files (2 new files [add] and 1 for edit [edit]). In that case everything works and git-tfs can unshelve TFS' shelveset into git branch., i.e. we can see it in crucible.
Issue2: One day our HEAD in git repo became detached from "master" branch. Once that happened crucible didn't see new changesets. I have fixed it with command:
git rebase HEAD master
I have created picture how this everything works on our project, may be it could be helpful:
You can integrate Mira and TFS with TaskTop and then use the code review tools built into Visual Studio.
Code Review added in Visual Studio 2012
TaskTop integration with TFS & Jira
These I think are your best options.