I am in an "internal" IT shop and we currently use ClearCase for version management. Our branching strategy is common for this with the main branch being reserved for live code and branching off main for project and hotfix type activities. Each project (and they overlap often) has a branch off main, we don't have multitiered branching.
We get the situation were we have to do merging between integration branches so that the release 4 branch picks up all of the release 3 changes (for example) before release 3 goes live and thus is baselined. And the number of times that a hotfix happens when a project is high and has to be supported.
However, this isn't really going to be possible within the TFS world as we don't want to have to drop to the command line to do baseless merging, however we need to have a highly flexible branching capability - something we have got really used to with ClearCase.
So ideally we want TFS branches to allow us to have a production baseline, to be able to branch off to do short term hotfixes, to be able to branch off to do projects - without actually knowing which of the branches will go live (and thus baselined) first. Having worked through all of the MS documents they all appear to be focused on product type environments - but we are mostly a support and enhancement shop.
I'm looking for recommendations/pointers - I've been a ClearCase admin and can quite happily juggle with branching mentally - but everything I come up with just doesn't look like it will fit with TFS - but this is most probably because my mental process is ClearCase-like and isn't in tune with TFS (yet!)
I haven't much experienced with TFS2010, but considering branches are now first class citizen with TFS2010, one practical solution would be to consider your enhancement as a "product" and create a patch branch accordingly.
I suppose you have read the TFS2010 Branching Guide.
It does include a branching scenario for addressing hot-fixes issues.
(from the "TFS Branching Guide - Scenarios 2010_20100330.pdf" document)
Related
We are trying to determine the best source control branching strategy to use at work. We use a VSO frontend attached to a GIT backend. We have 4 database environments, DEV, QA, STAGE and PROD. At any given time we have many teams working on different features that often leapfrog each other, in addition to a lot of ongoing database cleanup work (adding Primary and Foreign Keys, setting columns to non nullable, etc)
My idea is to maintain four persistent branches, one for each database environment, that reflect their respective database environments. Any team working on a new feature will branch from Dev, and at the point the work is done merge back into the persistent DEV branch. When the work is ready to go to QA it will be merged to QA, at the point it is ready to move to STAGE it'll be merged to STAGE and so forth. Any non-breaking database updates not tied to a freature (like making columns non NULLABLE) can flow as change sets without needing a feature branch, but every potentially breaking change will need to work as a feature branch.
Has anyone used this strategy? Did it work?
Is there a better branching model you can recommend?
Well, since no one ended up answering I will use my own answer for an update. It appears we will end up using this branching strategy, more or less as I originally described. The main difference is that the PROD branch will be called master, and the feature branches will be branched from master rather than DEV.
This is because the master/PROD branch is considered more stable than DEV. The previous environment where I had branched from DEV successfully was a single release-train. Since features are expected to leapfrog each other here we can't do that.
Also, all development will need to be done in feature branches. This is due to a limitation of the VSO GIT plugin however, since the mechanism for linking GIT pushes to VSO tickets requires that work be done in feature branches.
We are looking for guidance regarding Branching and Merging for TFS and multiple applications (some are COTS; some internally developed) with multiple development teams. Note that we currently utilize monthly release windows but are going to quarterly. We also need to be able to support eFixe and non-release development efforts (ie: regulatory changes that have to be implemented outside of a window). Based on current research we are focusing efforts on research of the following 2 options:
Option 1) Release branching per major application where each application would have MAIN, RELEASE and PRODUCTION branches (the PRODUCTION branch would support an eFix branch which would support eFixes and off cycle changes).
Options 2) Release branching for entire organization - MAIN, RELEASE and PRODUCTION branches would contain ALL applications.
A number of helpful branching suggestions here:
Visual Studio Team Foundation Server Branching and Merging Guide
WRT to your question my view is
Option 1) Individual application release branching
The is if your applications does not have too many if any dependencies on each other.
Pros:
Builds would be quicker
More flexibility to Cherry pick deploy components
Better for Continuous integration builds as you can build
and deploy little and often
Sign off and lock indivdual applications based on your quality quality gates
Easier to redeploy critical fixes
Merges smaller and possibly more frequent
Cons:
Possible management overhead for maintaing builds/deploy scripts
If there are application dependencies could introduce risks when cherry picking components
Require solid deployment framework for maintaining the assembly versions and labels.
Multiple deployment asset resources will be involved when deploying (instead of 1 deployment package)
Options 2) All applications release branching
Pros:
Easier to identify the version of all apps at any time,
Can deploy using Teardown and full deploy,
Less build and deployment scripts to manage
Lesse deployment asset resources to mange.
Easier to track/visualise release level merges/changesets
Cons:
Builds may take longer
Less release flexibilty if an application is not fit for purpose or contains bugs after code freeze/sign off
Harder to cherrypick deploy components
Production critical fixed may take longer to get rebuilt and deployed
Rollback is all or nothing depending on the deployment framework
May require full regression tests for minor fix deploys (depending on the QA controls)
I was reading many articles about version control systems like SVN, Git and various branching models (feature based, release based and others) but none of them did not seem to fit our project requirements.
We (team) are going to develop a framework, which will be used as core for different applications. So, there will be one framework and more than one different applications built on that framework. Each application will have usual project cycle: builds, releases... Framework itself won't be released but may have tagged different versions. During the development of application, we want to commit some common features to the framework (if we see that feature is great and future applications should have it).
So each application is like a separate branch of framework, but it will never be fully merged back (because it's a separate application) and there is need do some commits to framework (trunk). Some online articles such commits (without merging whole branch to trunk) gives as negative examples, so we are confused.
What version control system and branching model do you recommend for such development cycle?
So each application is like a separate branch of framework, but it
will never be fully merged back (because it's a separate application)
and there is need do some commits to framework (trunk). Some online
articles such commits (without merging whole branch to trunk) gives as
negative examples, so we are confused.
This part scares me a bit. If you are going to have a framework, then you need to take care of it like any other lump of code, and you don't want multiple versions running around for any reason except maintenance of existing releases or work on future releases. So each of your "application" projects can have a branch where they modify the framework as required for the application, but I recommend the framework trunk be updated often so that it evolves in a way that best serves the needs of all of your applications. In general, when branching for code going forward, you want to sync up with the master and put code back into the master as quickly as possible to avoid lots of work handling merges and also give others the benefit of the work.
You should put your framework in a separate area (or repository if you are using a DVCS like git or hg) so that it's distinct and may have its own release cycle if necessary.
The DVCSs are all the rage these days, git and hg being the most popular, so you should look into them. They have different ways of handling branching. Their power lies in the fact that there is no centralized repository so it's more flexible and reliable for larger teams.
I've recently been given the role of managing or development environment which includes:
Managing the version control system (subversion) in which we typically have one major branch which is released to production every 6 months, a maintenance branch which is released every 2 month to fix non-major bugs found by users and a couple of branches related to bugs which just can't wait for the maintenance release.
Managing our databases so that we have a development database for each branch of the code
We've not long moved over to using the version control system and have had the following issues:
Developers who work on a number of branches concurrently can quite often end up developing against the wrong database (we have around 15 developers)
A lack of a decent strategy for managing the release of branches into production and the propagation back into other branches
A lack of a decent strategy for managing the databases associated with each branch (i.e. should we keep a script which is aligned with the production environment and then a script to bring each database user in line with the needs of the branch)
I had thought of using a Virtual Machine for each branch of the code (i.e. A VM containing an Oracle Express database user, a Coldfusion Administrator with the correct setup for things like data sources, and development tools like the IDE and Tortoise).
I was looking for any suggestions anybody might have to help with any of these issues as I'm finding it really difficult to manage the process. I understand that no 2 companies have the exact same setup but I'd welcome any help.
I think that the best solution for you can be to start using continuous integration applied to your product life cycle strategy.
You can read about it over the web:
Continuous integration
Great open-source framework for continues integration!
I hope this helps you, but your question is quite hard to answer 'cause there are a lot of parameters to answer which always very from company to company, you should consider hiring a consultant to help you. He/She will have to come to your company and help you decide and implement.
I would start by asking each of the developers why this kind of mistake happens. If a developer has recently made the mistake, then get them to explain how they did it and what might help them in future. Also talk to developers that have not recently made a mistake.
I'm assuming that you have a server with Oracle and all the different flavors of the db running on it using different port numbers. In that case you would create a new db instance to go with each branch and the problem is how to help the developer set up a context before working on the branch.
Tortoise SVN is a nice tool, but perhaps this is a situation where it would be better to have some kind of small app that does the checkout, and remove Tortoise from the machines. The small app could keep a window floating on screen showing the currently active branch, and it could handle checkout and checkin, as well as making sure the right port number is used.
Which one is better? UCM or base ClearCase?
For paralel development, do we need UCM? Is using manual branching is error prone on base ClearCase?
Is serial development not meaningful? working on same branch?
One is not better than the other, UCM represents a different set of best practices that you can choose to apply on top of base ClearCase.
UCM is great at defining a coherent set of files (the UCM "component") that will be:
branched in the same branch
labelled ("baseline") as a all (all the files receive an immutable label)
referenced by other streams (list of baselines)
Parallel development can benefit from UCM because of the streams you can set-up in advance, in order to define your merge workflow. You don't impose anything, but if you finish a development effort on a sub-stream, the natural merge to do is a "deliver" to the parent stream. (As opposed to base ClearCase, where there is no "hierarchical organization" for branches: once you finish a task in a branch, you can merge your work to any other branch: there is nothing to remind you what could be a natural candidate branch for your merge).
But the other advantage is the definition of a configuration, i.e. the exact list of baselines (labels) you need to get in order to "work" (compile, or develop a new feature, or deploy, or refactor, or...).
Depending on the number of components you have to deal with, you will then adopt:
a system approach: every component is modifiable
a component approach: one component modifiable, the others non-modifiables: you only develop in one set of files, and use the others at a fix label for your compilations.
May I just add...
It really depends on the size and complexity of the development team working on the same project. For example, we have a large dev team consisting of 100s of devs from all over the world, and this team really benefits from all the features that UCM provides (as mentioned by master VonC above).
On the other hand, most of the teams in my organization are around 10 people, and they are all co-located at one location, and these teams really do not want to mess around with the deliveries and merges, so they choose to simply use base CC with basic branching strategy, e.g. one Integration/Release Branch, followed by each dev branch for each release, or personal dev branch. For smaller teams, we usually recommend them to use base CC because it is easier to manage.
Hope this helps.