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)
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.
In an environment (SQL Server, TFS, SSDT, VS) with around a dozen TFS SQL Server Data Tools Database Projects per solution (with database projects only) with four to five simultaneous branches, would you recommend using an integration branch or not? And why (not)?
Is it worth the overhead?
If not, how do we best perform merges between branches?
It totally depends on your teams workflow on how your branches relate to your workflow and release strategy. Let me give 2 different examples of where you would want an integration branch, and where you might not.
Example #1
You have 5 Feature Branches, some or all of them will be integrated together to create the next release. In this case you clearly want an integration branch.
Example #2
You have 3 branches representing v1 - v3 of the software that are all under development simultaneously. In this case you might not need an integration branch. All v1 code should be merged into v2/v3 branches, but not the other way around.
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.
We're an ISV that's completed our first app on force.com. It's an xRM-like app with extended workflow to build out complex campaigns (not simple marketing-like campaigns) and integration with on-premise software. The platform brings enormous value, and at the same time some challenges. Interested in other ISV experiences around the following:
Application upgrade process. Customers expect cloud app upgrade to "just happen". Reality is that there's inevitable manual pre- and post-upgrade steps that can fill many pages. We don't want to burden the customer with this, and at the same time while we're happy to do the upgrade work for the customer, we don't want access to customer data and the need for elaborate security assurances that come along with that access. A conundrum.
Development environment. Agile/scrum development relies on achieving full test automation and continuous integration, yet full automation beyond unit test seems difficult or impossible.
Background processing. Constraints on scheduled jobs, callouts, and futures, and issues with transaction management present challenges to traditional software development.
Curious what other ISVs have found.
Thanks!
I am now working at my second Force.com ISV and so have a fair amount of experience in releasing products on the platform (have seen 4 separate products releases, 1 which included 3 version releases and 1 including another version update).
If possible, you should try to remove any pre/post install steps that the user requires to do. It sounds tough, and it is, but its the biggest reason people don't adopt a product. The idea is that it is quick and easy to install, one click, and any extra effort detracts from the user experience. Ensuring your system is data independent is a good way of getting around the data security issues you referred to, and obviously you can offer a consultancy to do the upgrade work. A sensible idea might be to have a list of all the objects and fields that are affected by your products installation and then to do a check of the customer org before installing. I would also say that installing in sandbox and doing a couple of weeks user testing can highlight any problems you may have in future very effectively.
It is not true that full test automation beyond unit tests cannot occur and is actually very simple. The key is having the necessary framework setup. So you would have a central version control system where your code is stored (a key agile part). Then you create a script so that when code is committed, it runs an install on a SFDC org, running all tests and reporting back. You can then get this script to run a set of apex classes or upload a bunch of CSV files to put data in with either further fuller apex tests to run functionality or selenium running to do a set of tests. You can then also use this test data and script for knocking out demo environments for sales guys.
The governor and background processing limits are a bit tight, but they keep on being increased. Maybe you should integrate with Heroku or similar to do some larger external processing? I will say though I think it improves programming abilities in general, making you think about what it is your doing and the best way to do it. This then leads to a more pleasant end user experience. Batch apex jobs area a good way of doing this processing and you can use the asyncapexjob object to report back on the status f a run to users.
Hope that helps and gives you a different perspective!
Paul
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)