Using a continuous integration on my project, I need to checkout the code from latest sprint from BAZAAR as bzr://path/to/myproject/sprint/123
As this path is changing repeatedly (for each sprint), I'm currently using externals to create a bzr://path/to/myproject/current pointing to bzr://path/to/myproject/sprint/123.
So, I just need to change the externals to redirect the continuous integration tool to the latest project.
Is there another way to do this ?
What I don't want is to change the configuration of my project inside the continuous integration tool (CruiseControl.NET).
One option (might not be suitable for your teams' processes) would be to stop using a separate "sprint" location in bzr for each iteration's changes. Instead, just use a "trunk" (or perhaps your "current" above). If you are usually in a situation where you have multiple sprints having changes at the same time, then this would probably not be appropriate.
I suppose you can use a lightweight checkout.
bzr checkout --lightweight bzr://path/to/myproject/iterations/123 bzr://path/to/myproject/current
You can then use bzr switch to switch to the next branch (I'm not sure if it will work over the network):
bzr switch -d bzr://path/to/myproject/current bzr://path/to/myproject/iterations/124
After searching the web, I've found some articles about this question.
There are two solutions so far:
Automatically detect newly finished branch and build them. There is an example here using CC.NET. It is so applicable to my iterations.
Another way is to provide scripts to developer that execute most of the CI tool. This is not perfect, but this may detect issues before merging in the trunk.
Other references:
Best branching strategy when doing continuous integration?
Related
After reading and asking about how to deal with git, Github, branching, versioning and tagging, it looks like the best way to denote a new version of software, is by marking the last commit of a specific version with a specific tag.
A structure like this can be assumed:
Commit 1
Commit 2: Tag 1.0.0
Commit 3
Commit 4
Commit 5: Tag 1.1.0
Commit 6: Tag 1.1.0
Where once version 2.0.0 is released, most likely a 1.1.x branch is created to maintain the 1.1 release for hotfixes, etc.
Now I am wondering how it is possible to integrate this with a CI, like Travis for example.
What I do know is that:
A Continuous Integration system, like Travis CI, gets triggered on every commit to any branch, and it is possible to enable/disable this per branch.
I am struggling to figure out if it possible at all to start a build once you have tagged a certain commit, can anyone explain me how this can work?
The idea behind Travis and Continuous Integration systems in general is that first word: Continuous. You want it running on every commit because your tests should always be working (except when you know they're not). Running it on each tag isn't very CI-like, as it prevents the continuous part from happening, and defeats the entire point of it.
CI allows developers to catch bugs before they might've been noticed, even if your contribution docs say that you're supposed to have the build passing before pushing doesn't mean people listen. Travis, in particular, allows for lots of variation and multiple builds per commit with different setups, so you can test for a case that you might not think of when developing locally.
If you really just want to run it on each tag, you could write your build script to exit early if there wasn't a new tag defined. Travis defines a bunch of environment variables that could help you detect it.
Based on my SO post I've been using Github as our VCS and with the help of the windows Github tool it's been great to handle those basic operations. Yet for merge like operations, I've to get back to Gitbash (SO Post) but thats ok.
So, the source code level VCS is in place. Now, we want to take a step
forward and use its simple issue-tracker to have "release control". For us,
this means being able to track each stable build (it can be a new
feature or bug fix, etc..) The idea is to create issues, tie them to a
milestone and use Github commit comments to close the issue and mark
it as a stable release/build. Where does tagging come in picture?
I've learned that we shud have a "development" branch for ongoing changes and periodically merged with the master (i.e. each stable build).
Is this the right way? We need to be able to go back to release / build 1.0 from 1.1 - sort of rollback just in case its required anytime in future (is this possible? how?) Is Github suffie or do we need to use some external tools as well?
Please share your experience and suggestions.
As I wait for other expert comments, I'd like to share a model that I've come across and seems great!
A successful Git branching model (SO Post)
To summarize, here is how I can address my basic needs (and scale it as and when required) -
Initially maintain two branches "master" and "development"
Master should always have a stable version and development has an ongoing source (might not be stable)
In the future, if we need to fix a bug after release, we can create a hotfix branch and when stable merge it with master/development
A good thing I found is that I can maintain stable releases in form of tags (i.e. new tag for each new version)
Eventually, master branch will be merged with development as we proceed with each stable version
There's a lot more that can be handled with the above model but I see my initial concerns addressed. Any better suggestions?
I'm running an open source ecommerce store (nopcommerce) and have made a lot of customizations to the store.
Every time a new version of the software is released, I use winmerge to try to detect which files have changed, and then merge these changes into the project. This works OK but as my customization have grown, this task has become increasingly problematic.
What I'd really like to do is be able to get a diff from my current version to the new version, and then go through and apply the changes that I want.
If I use TFS for this, is there a standard way to accomplish this? Perhaps a 3-way merge app would do the job better?
To complicate things a bit further, I'm using the theming support to add my modified views in another location, so the changes from version to version need to be figured out and applied to the files in this additional folder as well.
In fact this is where the big headache comes in- determining which changed I made, and which ones are new changes from the new version.
nopCommerce hosts its source code in Mercurial via CodePlex. All you really need to do is clone their repository and make changes to your local clone. Then, you can either keep up with their modifications or wait until the next release comes out, then get an update from their repo and merge it with your changes. Mercurial, being a distributed version control system, just does merges well, and you will have fewer problems if you try to do something manually for yourself using Subversion, TFS, or anything but Mercurial. Go download TortoiseHg, which gives you both a nice GUI and the command-line tools for Mercurial. TortoiseHg comes with the KDiff3 merge tool, but I highly recommend Beyond Compare. It's not free, but I'd pay for this software a hundred times over.
As always, if you need help with using Mercurial, see the Hg Book.
I have used both TFS and Subversion and I strongly recommend Subversion (source repository) with TortoiseSVN (command line) and VisualSVN (integrated into Visual Studio).
With these tools, it is very, very easy to find out exactly what files have changed and, more importantly, rollback to a previous version in the event that something goes horribly wrong.
You can also add CruiseControl continuous integration to automatically build your solution and run unit tests on each checkin to ensure that you didn't inadvertently break something.
I once ran across a commercial tool for Windows that allowed you to "stash" code changes outside of source control but now I can't remember the name of it. It would copy the current version of a document to a backup location and undo your checkout in source control. You could then reintroduce your backed up changes later. I believe it worked with multiple source control systems. Does anyone know what program I'm trying to describe?
The purpose of my asking is twofold: The first is to find a good way to do this. The second is because I just can't remember what that darn program was and it's driving me crazy.
Git: http://git-scm.com/
You can use git stash to temporarily put away your current set of changes: http://git-scm.com/docs/git-stash . This stores your changes locally (without committing them), and lets you reintroduce them into your working copy later.
Git isn't commercial, but is quickly gaining many converts from tools like Subversion.
I think the product you're thinking of is "CodePickle" by SmartBear Software. However, it appears to be a discontinued product.
The term that seems to be used for the type of functionality you're looking for seems to be 'shelving'.
Microsoft's Team system has a 'shelve' feature.
Perforce has several unsupported scripts, including p4tar and p4 shelve
There are several 'shelving' tools for Subversion, but I don't know how robust they are.
I'm no git user myself, but several of my colleagues are, and they seem to like it precisely for this purpose. They use the various git wrappers to commit "real" changes to the SCM system used by their company, but keep private git repositories on their drives which they can keep their changes which they don't necessarily want to commit.
When they're ready to commit to the company's SCM server, then they just merge and commit upstream. Is that what you're looking to do?
Wouldn't it be a better idea to store your private changes in private branch, using e.g. svn switch to change to main branch whenever you need to?
Mercurial has the Shelve Extension which does what you want.
You can even select which changes from a single file that you want to shelve if you really want.
In Darcs, you either don't record the changes you want stashed (it asks you about including each change independently when you record a new patch), or put them in separate patches that you don't push upstream.
There's no need to fully synchronize your local private repos with public/upstream/other ones. You can just cherry pick the patches you want to push elsewhere. Selecting patches can also be done with patterns, so if you adopt a naming convention for your stashed patches you can push everything but them easily.
That way, your private changes are still in revision control, but they aren't shared until you want them to be.
I found an excellent article about obtaining similar functionality using Subversion branches:
Shelves-in-subversion
And then there's the old fallback... 'patch', or even the old "copy everything to another location, then revert".
Both of these are less convenient than using tools that are part of most VCS systems, though.
At my work we currently use Aegis version control/SCM. The way we have it configured, we have a bunch of tests, and it forces the following things to be true before a change can be integrated:
The full set of tests must have been run.
All tests must have passed.
With test-driven development (TDD) these seem like sensible requirements. But I haven't heard of any way you can do this with any other version control systems. (We're not currently planning to switch, but I would like to know how to do it in the future without using Aegis.)
I would be interested in any VCS (distributed or not) that can do this, I'm also interested in any plugins/extensions to existing VCS that allow this. Preferably open source software.
ETA: OK, it seems like the usual thing to do is have VCS + continuous integration software, and running the tests is automated as part of the build, instead of as a separate step. If I understand correctly, that still lets you commit code that doesn't pass the tests, just you get notified about it -- is that right? Is there anything that would stop you from being able to integrate/commit it at all?
IMO you're much better off using a continuous integration system like CruiseControl or Hudson if you want to enforce that your tests pass, and make the build rather than the check-in dependent on the tests results. The tools are straightforward to set up, and you get the advantages of built-in notification of the results (via email, RSS or browser plugins) and test results reporting via a Web page.
Regarding the update to the question, you're right - VCS + CI lets you commit code that doesn't pass the tests; with most CI setups, you just won't get a final build of your product unless all the tests pass. If you really want to stop anyone from even committing unless all the tests pass you will have to use hooks in the VCS as others have suggested. However, this looks to me to be hard to deal with - either developers would have to run all of the tests every time they made a checkin, including tests that aren't relevant to the checkin they are making, or you'd have to make some very granular VCS hooks that only run the tests that are relevant to a given checkin. In my experience, it's much more efficient to rely on developers to run the relevant tests locally, and have the CI system pick up on the occasional mistakes.
With subversion and git you can add pre-commit hooks to do this.
It sounds like you need to look at Continuous Intergration (or a variant of).
Think Git has a hook on apply patch too.
Subversion and git both support this via pre-commit hooks.
Visual Studio Team System supports this natively via checkin policies.
I believe that Rational ClearCase also supports it, though I've never seen that demonstrated so I can't say for certain.
We use git and buildbot to do something similar, though not quite the same. We give each developer their own Git repository, and have the buildbot set to build any time pushes to one of those repositories. Then there is someone who acts as the integrator, who can check the buildbot status, review changes, and merge their changes or tell them to fix something as appropriate.
There are plenty of variations of this workflow that you could do with Git. If you didn't want to have someone be the integrator manually, you could probably set the buildbot up to run a script on success, which would automatically merge that person's change into the master repository (though it would have to deal with cases in which automatic merge didn't work, and it would have to test the merge results as well since even code that merges cleanly can sometimes introduce other problems).
I believe continuous integration software such as team city allow you to do pre-commit build and test. I don't know of any vcs that provides it directly...there may be some like the one you use but I'm not familiar with them.
You can also use pre-commit hooks in Perforce. And, if you're a .NET shop, Visual Studio can be configured to require "gated" checkins.
VSTS with custom Work Items, right? I don't see anything wrong with using this. Built in reporting. The choice to automate. Why not?
What I do here is following a branch per task pattern which lets you test the code already submmitted to version control but still keeping the mainline pristine. More on this pattern here.
You can find more information about integration strategies here and also comments about Mark Shuttleworth on version control here.
Most CI implementations have a mechanism to reject check-ins that don't meet all the criteria (most notably pass all the tests). They're called by different names.
VCS should do what they do best.. version source code.
TeamCity - Pre-tested commit
TFS - Gated check-ins