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?
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.
I am new to Perforce and find it really hard to follow its workflow..
I have used Mercurial before (not in any advanced ways), but what I lack most in Perforce is the idea of named branches.
Let me explain what I'd like to do:
I get the latest revisions of all files and want to work on a new feature/story/task..
I create a brach, say "Feature 3021"
I code, save changes in this branch (hg commit)
I can save changes to a central server (hg push)
When I'm done coding, I merge the changes from "Feature 3021" with the main branch (default, master, etc.) - after that the main branch has the code I wrote
I can close the named brach ("Feature 3021") so that further commits are not possible.
I don't need this exact behavior in Perforce, but something analogous. I know that Perforce is centralized, so the commit-push step would be probably one, but this is a minor problem here.
All I care is to be able to save my work in version control at any time, even if it's not 100% ready - perhaps to a different branch. I'd also like other users to be able to be able to get my code (from this different branch), but only if they want this - the default branch should stay unafected as long as I don't merge my changes with it.
Is it possible? I am using Server 2012.2
Can you upgrade to Server 2013.1 or later? There's a great feature there, called Task Streams.
Here's some references:
http://www.perforce.com/blog/130627/task-streams-even-if-you-are-classic-perforce-shop
http://www.perforce.com/blog/130206/task-streams
http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html
The analogous flow in Perforce would be:
Maintain a main-line "branch" at some path, say //depot/default
To create a feature branch, integrate from //depot/default to //depot/feature-3021
Work under //depot/feature-3021 and submit
When you are ready to merge back, integrate //depot/feature-3021 to //depot/default
Regarding closing the branch after its use, there are a couple of options that I can think of. You could either change permissions or simply delete it. The delete could always be recovered.
Also note the paths don't need to be at the same hierarchy. A more reasonable branch strategy might use paths like this.
Main-line: //depot/default
Developer branches: //depot/dev/${user}/${feature}
I recently started taking an interest in using a branching model similar to Vincent Driessens Git branching model. We have multiple developers working on the same project so using different branches for different features is a big plus for us. The model states that after a feature is developed, it is merged back into the Development branch, and on a certain time a release branch will be created from it.
Now my problem is that I don't know who added what to the dev branch since the last release, but I do want to present a list of changes that will be implemented for the next one. So the question is, how do I know what features have been added to the dev branch?
We're using TFS for version control. As far as I know I have the following options:
Better labeling and commenting of versions (currently there is no labeling and little commenting)
Linking TFS tasks to versions (not sure how to create a nice list of that yet though)
Maybe I should just follow my own options above but I was curious about how you guys deal with this.
First I would suggest you take a look at the TFS Branching and Merging Guide as it will likely answer most of your questions.
how do I know what features have been added to the dev branch?
I think the "develop" branch in Driessen's model is most closely equated to the "main" branch in the TFS guidance. I would suggest that you shouldn't merge changes into main unless they are already planned to go into the next release. Then when you are ready to release you simply branch from the latest version of main.
Keeping track of what features are intended for the next release is something that would be handled by the work item tracking system.
Separately, you may find the Track Work Item feature of Team Explorer to be helpful.
We have team of 10 developers who works parallel for different features, sometimes these features use common code sometime no.
And now we're changing our process to branch-per-feature and it seems mercurial is more suitable for such development.
I see this process so:
1. make release branch (r-b) from default(trunk)
2. make feature branch (f-b) from default(trunk)
When developer thinks his feature is done he can merge f-b to r-b. When it's time to go to QA we merge all finished f-b to r-b and create release for our QAs.
Questions:
When QA finds a bug developer should modify his f-b and merge it again to r-b. Does it mean that developer just switch to his f-b and start fixing the bug and then makes simple merge f-b to r-b again?
When release is passed QA it goes to PROD - how can we freeze changes? "hg tag" is good choice but someone can update tag if he really wants it.
Thanks
If you're going to merging into specific release branches then your feature branches should be branched from the release branch, not the trunk. It is simpler to merge with the parent branch than a non-parent branch.
1) If you really want to do feature branches then each bug would have its own branch. This will help keep bug fixes separate from new features. After all, it's branch-per-feature not branch-per-developer.
2) Hg tag is what I have used. You are right that someone change move a tag if they really want to, but tags are versioned and you can install hooks on the main hg repo to throw alerts if a tag is moved. I really wouldn't worry about tags being moved unless you can't trust your developers, in which case you are screwed.
The answer to your first question is 'yes'.
The best way to freeze for release is to have a separate release clone that only the release manager can push/pull changesets to. Just because you're using branches doesn't mean multiple-clones don't have a place in your workflow. Have a clone that QA does final pre-flight testing on to which developers can't push changes makes for a great firewall.
Also, consider using bookmarks for your feature branches. Since, as I'm sure you know, Mercurial named branch names never go away the git-like bookmarks work well for sort lived concepts like features and bugs.
I have been tasked with coming up with a strategy for branching, merging and releasing over the next 6 months.
The complication comes from the fact the we will be running multiple projects all with different code changes and different release dates but approximately the same development start dates.
At present we are using VSS for code management, but are aware that it will probably cause some issues and will be migrating to TFS before new development starts.
What strategies should I be employing and what things should I be considering before setting a plan down?
Sorry if this is vague, feel free to ask questions and I will update with more information if required.
This is the single best source control pattern that I have come across. It emphasizes the importance of leaving the trunk free of any junk (no junk in the trunk). Development should be done in development branches, and regular merges (after the code has been tested) should be made back into the trunk (Pic 1), but the model also allows for source to be patched while still under development (Pic 2). I definitely recommend reading the post in its entirety, to completely understand.
Pic 1
Pic 2
Edit: The pictures are definitely confusing without words. I could explain, but I would basically be copying the original author. Having said that, I probably should have selected a better picture to describe the merge process, so hopefully this helps. I'd still recommend reading the post, however:
The simplest and most usual way I've seen branching work is off two premises. Trunk and Release. I think this is known as the "Unstable trunk, stable branch" philosophy.
Trunk is your main source. This contains the "latest and the greatest" code and is forward looking. It generally isn't always stable.
Release is a one-to-many association with trunk. There is one trunk but many releases that derive from the trunk. Releases generally start with a branch of the trunk once a particular functionality milestone has been hit so the "only" things left to go in for a particular deployment should just be bug fixes. You then branch the trunk, give it a label (e.g. 1.6 Release is our current latest Release), build and send the release to QA. We also push the version number (usually the minor number) of the trunk up at this point to ensure we don't have two releases with the same number.
Then you begin the testing cycle on your release branch. When sufficient testing has been perfomed you apply bug fixes to the release branch, merge these back to the trunk (to ensure bug fixes are carried forward!) and then re-release a build of the branch. This cycle with QA continues until you are both happy and the release is finally given to the customer(s). Any bug reports from the customer(s) that are accurate (i.e. they are a bug!) start another QA cycle with the branch in question.
As you create future releases it is a good idea to also try to move older customers onto newer branches to reduce the potential number of branches you might have to back-patch a bug fix into.
Using this technique you can deploy solutions using your technology to a variety of customers that require different levels of service (starting with least first), you can isolate your existing deployments from "dangerous" new code in the trunk and the worst merge scenario is one branch.
My first recommendation would be to read Eric Sink's Source Control HOWTO - specifically the branches and branch merge chapters.
We have 3 containers - DEV, MAIN, and RELEASE for our work. MAIN contains all our "ready-to-release" code and we tend to think of it as "basically stable." DEV/Iteration (or DEV/Feature, or DEV/RiskyFeatureThatMightBreakSomeoneElse) are branches from MAIN and are merged up when the Iteration/Feature is ready to promote up past the DEV environment. We also have TFS builds set up from the DEV/Iteration branch and the MAIN branch.
Our RELEASE container contains numbered releases (similar to the "tags" container used in many Subversion repositories). We simply take a branch from MAIN each time - I like to say we're "cutting" a RELEASE branch to signify this shouldn't have a lot of activity going on once the merge is finished.
As for VSS->TFS - Microsoft supports an upgrade path which should keep your version history, but if you don't need it the history, I would just get the latest version from VSS, check it into TFS and archive the VSS repository.
One final tip - get your team members familiar with source control. They must understand branching and merging or you will be stuck doing a lot of cleanup work :).
Good luck!
The subversion book describes some common branching patterns. Maybe you can also apply these to TFS.