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
Related
We have a project on Snap CI but since it's going away we have to switch to another tool.
GoCD is our favorite but there is an important feature I am wondering if it's supported: Branch tracking.
Snap CI supports branch tracking which is currently enabled in our project: 'This repository has automatic branch tracking enabled for all branches starting with ***':
I tried to set up GoCD to do exactly this. But I couldn't find a way to achieve this behavior. The only thing I found was the feature branch / pull request plugin.
Do you know if such a feature is supported or how I have to configure the FB/PR plugin?
Thanks!
We wanted to do something similar and were faced with the same problem. In the end, we couldn't get direct branch tracking, but created a GoCD API client that created pipelines from a template, and the branch of Git material is set to a parameter (e.g. #branch). The client gets run manually when branches are created, but it could quite easily be adapted to run from hooks to automate it.
Downvote if you want... but I need a set of simple basic steps that we can follow. We have VS Enterprise, no GitHub add-ons installed. We have a an empty repo created on GitHub. What do each of the developers do after that? There's a local repo, right? Should there be another project on the local machine that commits to the local repo or do we open the project in the repo? If yes, how do we create that other project? What about the .sln file that VS lovingly puts in a separate folder? We have been at this for hours and believe me we have tried every combination of commit/push/sync/goat sacrifice except the right ones. We cannot reproduce consistent results such that two developers can work against the same remote repo. Sometimes one developer can push and he doesn't see the files pushed by the other developer. Sometimes the Commit Message text box lights up but the Commit button is disabled. I thought I was reasonably intelligent until I started working with GitHub.
I'll give you the broad steps you need to do. You may need to fill in a bit of the detail. THis is how I would work it. I am sure you could get many other opinions.
Create the repo on GitHub (which You already have done.)
Each developer should then go to the GitHub repo and fork the repo under their own GitHub account.
Each developer then needs to clone their repo to their local machine. (That's the beauty of Git. Every developer has the entire repo locally.) You can do this in VS2015 by choosing: File -> New -> Repository -> Clone.
Go to your on-line repo and get the URL of the repo that you will be cloning. Enter it into the New Repo dialog box in VS.
When working on the project, each developer should create a temporary feature branch, which they push to their own GitHub repo. They can then push their work as often as they want without it conflicting with other developers.
When a developer thinks that their work should be merged into master, they should go to GitHub and issue a "Pull Request" for their feature branch.
Their PR can then be discussed among the team before it is accepted.
Once it is accepted and merged into master, the developer can delete their feature branch locally and on GitHub, if he likes.
Since "master" on the team repo has now been updated, each developer will need to pull down master from the team repo to update their own local and remote repos.
It sounds more like an how-to-use git issue. You probably first need to see how two collaborators work on same project with git. I donot think either VS or GitHub has anything to do here, as both only provides you git gui tool regarding this issue.
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. :)
What I want to do:
I want to set up Continuous Integration with Team City for a project that's hosted on GitHub.
What's Currently Working
I'm properly connected to GitHub. Commits, pushing, etc etc all seem to be fine.
TeamCity is set up and I can kick off a build which will run and run my unit tests, but...
What's Not Working
When I do a TeamCity build, it looks like it's pulling down code from GitHub before doing the build or running unit tests. I want to trigger a TC build when I do a commit, before it does the push to GitHub. I don't really want it to pull any code out of GitHub before running the TC build. This doesn't seem to be working at all.
I've set up a BuildTrigger which is a VCS Trigger. I've checked the box that says Trigger a Build on Each Check-in. I added a rule to the BuildTrigger with the VCS (Github) source and my username.
When I do a commit, I don't notice TC doing anything. When I then push the commit to GitHub, TC doesn't do anything either. I see no builds queuing or anything like that.
Any clues on what I'm doing incorrectly?
Thanks!
Have you looked at TeamCity's pre-tested commit feature? It doesn't work exactly as you described you would like your workflow to operate, but it might be useful. I've used it with Subversion in the past and it works pretty well, I haven't used it with Git but JetBrains state it also works with Git.
However, the most common workflow for Git is to create feature/bugfix branches for everything you do, which allows you to commit and push freely, and merge to master when you are ready. GitHub makes the merge (and optional code review) step painless and TeamCity has built-in support to automatically build branches, see the TeamCity documentation on feature branches for specific details it provides.
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.