I am designing a branching & merging strategy for my project (We use TFS). Project has plans to have multiple released versions. Currently we are testing v1.0alpha and working in v2.0
The plan is:
After imminent green light from testers, version v1.0 will be released to one client.
Version v1.1 (already in dev) will be deployed to 5-6 clients
Version v1.2 would be installed to dozens of clients.
etc.
We will try to force upgrade of old clients to most recent versions but due to the nature of project and market it can be months (years?) for clients to upgrade.
We want to use standard gitflow but seems more appropriate for having a single version. I have designed a simplification of gitflow:
The approach is:
If a client wants a bug fixed, we will fix it in the Release branch of his version and he has to upgrade to the latest revision of his version. For example client in v1.0 that has a bug would have to upgrade to v1.0.5. If the bug happens in other versions we will fix it there.
If the client wants a new feature we will develop it in the latest version and force them to upgrade if they want it. For example client in v1.0.5 that wants new version will have to upgrade to v1.2
If all the clients of a given version upgrade we will delete that Release branch. For example when the client of v1.0 upgrades we will burminate v1.0 Release branch.
So my questions in order of importance are:
Will my approach work? Any problems that you can see?
Does git-flow have any pattern for this "multiple versions scenario"?
Gitflow has a Master branch. Is it ok not having a Master branch? Could we consider the different Release branches as "Master"?
How will you name Dev and Releases branches?
Your approach should work. There is nothing magical to GitFlow, and variations catering to your needs are fine. Git itself has no issues with a different workflow. A good example is Github flow, take a look at http://scottchacon.com/2011/08/31/github-flow.html .
A few things you could consider:
a) "Principle of least surprise": Try to keep as close to a standard as you can. That means you i) point devs to available documentation on the web instead of writing up everything ii) make it easier for new devs to enter or just work with your projects.
Thus, you should keep the master branch, not because it is needed - it is not, but because it might confuse people when it is not there, and you would have to explain that for years to come.
Branches in git is "just" names (well, a bit more, but you get my meaning), so the only reason to name them the same is convention - making it easy for people.
b) How many devs are working on the projects? If there are many, you could consider the Dev branch an integration branch, and use the master branch as the stable branch. Having a dev branch that you allow to be unstable might solve many issues with many devs. Two teams committing, one from feature and one from a hotfix, the build goes red, the teams blaming each other, the third team try to get out a new release branch, but can't. Having a stable, always green build master branch, which you even could protect with pull requests, is very nice, and makes for a more relaxed environment.
2) Basic Gitflow is centered around a release, so not quite. You have multiple releases at the same time. So you are nearly there, but standard tools, like [Jakob Ehn's] (https://github.com/jakobehn) Gitflow extention to Visual Studio - which is supergreat - will make you try to close a release before you are allowed to open a new one. Ask Jakob to relax that, and the tool will work for you. Otherwise, just follow the convention, but do it manually - that works too.
3) See point 1 above about master and why it might not be a good idea to not have it. But of course you can consider the release branches as kind of masters, but they don't really behave that way in your description. And if so, which one is the real master, the one you create feature branches from, and the one you regard as the latest? Having a stable master solves a lot of questions that pops up without.
4) Dev or Develop, then features should have a name of the feature as close to what it does as possible, like Dev/NewHelpPage, or Feature/NewHelpPage (to be closer to gitflow convention). Release branches, it looks like you already follow the semantic versioning (http://semver.org) principle, so why not use that: Release/V1.0, Release/V1.1 and so on. A hotfix branch is then Release/V1.0.1 .
Let the naming be so that devs easily understand what it is, preferably without needing to have to ask anyone around.
Keep it simple, follow conventions as far as you can, and it tends to work out. Git itself works for mostly any branching scheme.
[Edit]
Just had a quick chat with Jakob, and he said he had requests to support support-branches, which is probably what you are really after. He also pointed to this excellent post on different gitflow scenarios, at the bottom there is the flow for support-branches.
Related
We are using visualstudio.com TFS to store the source code. We have DEV, STG and PROD branches. now I want to automate build and release to IIS server.
But it looks like to me that TFS compiles the code from the branch where I commit to, and that's the only build, after that I can install the same binary on all the servers.
But it doesn't seem to be ok, because what if we find a bug on the live code, so we need to fix it, but we already have new code in DEV, and we don't want to revert, and install the old code with the fix on the dev server?
What I think we should do is to merge the code from DEV to STG, from STG to PROD, but I couldn't find any module for that. And it looks strange, I would be surprised if I am the only person whats to do this, especially because it is doable with Jenkins.
thanks
I typically discourage automating merging of code between branches; merging should be a deliberate action. When someone expresses that desire, it's usually a sign of a problem with the branching model and deployment model they're using.
Code promotion branching (where you have one branch that corresponds to each environment, as in the scenario you described) is a bad practice because it encourages you to build different sets of binaries for each environment. You build something for a lower environment, test it, validate it, then totally disregard that testing and rebuild from source. That should terrify you, especially for production branches -- you have no idea if what you just built is going to work properly.
Current thinking is to minimize the number of branches you have, and instead isolate in-progress work behind feature toggles so that features that aren't ready for production can simply be disabled, but still allow deployments to take place. With sufficiently mature feature toggling practices and testing practices in place, you can actually eliminate branching entirely and work out of a single branch, promoting binaries to production whenever your automated and manual QA process deems the version they're testing is good.
Assuming you're using TFVC, if you want to maintain a code promotion branching strategy, then you'll need to maintain multiple builds and releases, one for each branch/environment. Typically, in this kind of scenario, I'd eliminate the stage branch entirely. Anything that goes to the Dev branch is built and deployed to Dev. Anything that goes into the Prod branch is built and follows a deployment pipeline from staging->production. Hotfixes can go directly into the prod branch and be merged backwards. There are tons of strategies for branching; you'll need to read up on the subject and design a branching and release strategy that works best for your team.
I mean is it ok to have v1.0 as main branch and v2.0 as subbranch? And what if I'll create v3.0 SDK, subbranch of a branch v2.0?
OR
create new repo with "v2.0"/"v3.0" postfixes?
So the question is: what is the best way to support multiple different versions of your SDK and in the same time keep them in one place ?
Thx.
I would definitely create different repos per version. Assuming that those versions are different enough to be called 1.0, 2.0, 3.0. That will make life really easy for you in order to manage pull requests. Also better when it comes to branch generation.
IMHO, if you keep only one branch alive and overwrite versions, could be a mess in the end. Imagine that you have a new feature under development (v1.0) pending from an specific commit, whilst v2.0 has been improved and it os ready to be delivered. Sum up a pull request from a developer that has fixed loads of bugs in an early release of v1.0....
In this case, again IMHO, divide and conquer. Repo per version. Branches per status (feature branches, stable branches, release branches), and pull requests to handle external changes.
Hope you like it!
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What is a version control system? How is Git useful?
I am new to Ruby on Rails platform, and so this may sound a little naive.
Why and when do we store our work in a version control system like git?
I mean what is the advantage of it ! Can't we just keep it in our local machine ?
Advantages for using git/source control:
For yourself
Remembering what you have coded and when you did it
Being able to compare what you did to previous work
Allow you to work on something experimental, and if it doesn't work switch it back to where it was before
Working with a team
It makes working with others easier - you can work on the same file at the same time and really easily combine your changes.
It will allow you to work in multiple locations and easily have the most recent code
It will help in deploying your code to a server
Git workflow for teams
Git branching model
When to store or commit your work:
You want to do this each time you finish on a particular "idea" or piece of work you are working on. This means you can have a useful commit message and can go back im time to that feature you just wrote or that bug that you just fixed.
How often and when to commit
Reasons for using Git over other source control
Its fast (switching branches is really fast and you have a local copy, so you dont have to communicate to a server for a lot of things unless you want to push or pull changes to the server)
Yes, this seems quite naive, but every question is worth asking!
First of all, using a SCM (software configuration manager) will greatly help you in a number of scenarios:
trying out experimental features without touching the main code
developing several independent ideas at the same time
recovering from failed changes, whenever they are complex and include changes in multiple files.
tracking the exact code used in a specific release, to fix a reported bug.
This doesn't even start to touch the infinite amount of work you'd have if working in a team without SCM.
And using a SCM doesn't involve network, git and any other distributed SCM is equally valid for local development, as the repository is all in your computer. You just don't pull and push.
The choice is not whether to store code in version control versus storing it on your local machine. In fact, unlike other version control systems (like Subversion, known also as svn), Git does not need a server to run.
Version control makes it easy to understand what changes were made, view and restore older versions of files, and even import changes from one version to another.
RETRIEVAL: Imagine you are working on a project on your own. You delete an old file you don't think you need anymore. A week later, you realize that the file was very important. If you use version control, you can see what the file looked like just before you deleted it, and restore it as if it were never deleted. Also, most changes committed to version control contain messages; if you join a team and the previous developer used version control (with good commit messages) you can get an easier context for when changes were made and why.
MULTIPLE RELEASES (BRANCHES): Now imagine that your software is version 1.0. You're busy working on version 2.0, but someone files a bug. What can you do? With version control, you can zoom back to version 1.0, make some changes, and then create version 1.0.1. Most version control platforms even let you apply the changes made in version 1.0.1 onto the work you're doing in version 2.0.
MULTIPLE FEATURES: Your software is so successful, you start releasing it weekly. However, not every feature is ready for release. First you start working on the widget feature, than you start working on the doodad feature. If you work on both of these at the same time, you may have two half-coded features in development at the same time, and nothing is working well enough to release. With version control, once one of the features is done, you can merge it into the "main" release as if you wrote it in one day.
COLLABORATION: Finally, now imagine that you're in a team of five or six developers all working on the same code. Naturally, you don't want to email zip files of code back and forth, especially when every developer is working on a separate feature. With version control, you can have a single history, to which all of your developers write and read.
Naturally, some of the above can be done by keeping multiple copies of the same files in different adjacent directories. The benefit of version control software is that it can handle much of the work for you while avoiding duplicating the same file over and over on your disk.
Long winded--sorry--but hope that helps!
Advantages of using git:
Code will be safe in remote repo, even if the local project crashes
You can try out new things without worrying about previous works as they can retrieved
The code can accessed from anywhere in the world
When working in team, all the work will be stored in a single place so that it will be accessible to everybody in your team
Each and every change can be tracked easily, who did it and when they did it
Deployment of application will more easier
You can have multiple versions/branches so that it will be easy for you to identify the new features added to the application in every version
you see #arulmr, #kieran-andrews, #Jeff and #rewritten that post many advantages but still if you want learn more in details you can see below links
1) http://git-scm.com/book/ch8-1.html
2) http://www-oss.fnal.gov/~mengel/git_vs_subversion.html.bak
3) https://git.wiki.kernel.org/index.php/GitSvnComparison
4) http://www.wikivs.com/wiki/Git_vs_Subversion #History, Architecture, Licensing, Performance, Features of git and svn
now the difference between git and subversion
1) http://boxysystems.com/index.php/5-fundamental-differences-between-git-svn/
I've currently got a number of Team Projects all happily managed by TFS.
I have one project, a windows app, that is currently in use and before I ported the code base to TFS, we manually used to maintain both the production build and a new development build using scripts to copy/merge the files.
e.g. App1 v1.x - production and
App1 v2.0 in development.
Before TFS we manually "merged" to bug fixes from the development build into the production build - so where applicable bug fixes from v1.x were also fixed in v2.
In this particular case v2 is quite different, re-factored ui, etc. The question I have is what is the best way of porting this scenario to TFS.
As I see it I have two options:
Create a new Team Project and continue manually "merging" applicable
code files.
Create a brand from the current project v1 and replace / overwrite the project piece by piece in VS so that the source control can manage the changes back to the Main team project.
V2 has a few additional class libs too - if that makes a difference.
Typically, this is the strategy we use to do branching and merging:
The project starts. All team members are working on version 1.0 in the single CURRENT branch.
Project approaches a milestone or release. Make a branch that will be used to stabilized the code for production in PROD 1.0 branch. Now half of the team stabilizes the product on the branch and half of the team continues doing new (riskful) stuff on the CURRENT branch.
PROD 1.0 branch is ready and delivered in production. The branch stays intact to provide maintenance and support on the delivered version. Fixes are made on the PROD 1.0 branch and merged into the CURRENT branch.
Project approaches another milestone or release. Make a new branch that will be used to stabilized the code for production in PROD 2.0 branch. The same mechanism is used as described before.
Using this branch-per-release strategy, you always have a branch per shipped and to be maintained version in which fixes can easily be propagated forward and backward between versions and the mainstream CURRENT development line.
With this respect, we use a TFS team project for multiple releases of a certain product. This limits the overhead creating and maintaining the project spaces.
In short...To branch!
It seems your code between versions is that much similar that you should be fine by simply branching your new release.
In general, changing to a new Team Project makes sense if you have one or more of the following:
a totally new bread of requirements and/or different Work Item types
completely different technology, in other words you have radically changed the design & merging is more loss than gain
need to store docs & other tokens in another SharePoint site
different development methodology - process template
different teams of people working on both sides, possibly want to restrict users from viewing v1 or v2
plan to release both products in completely different release cycles
need for totally separated reports
Reading your post I don't recognize the need to go after creating a new Team Project - of course I might be wrong.
In case you decide to go with the branch variant you could be greatly benefited from the impressive Visual Studio TFS Branching Guide 2010, on how to shape the structure of your codebase.
Question:
What is the best practice for creating branches for development and release based on the information provided below?
Background:
I work in a small development team (2.25 frontend, 2 backend), and we have a yearly release schedule. Our environment does not allow for patches or services packs mid-year, but every once in a while if our user's environment changes we will release a "recompiled" version with a few bug fixes thrown in (on the current stable version).
Currently we do all of our development on the mainline and then create a branch (5 so far) for the code freeze and do minor bug fixes and the bulk of our testing. Once the version is sent out for layering and deployment we merge these bug fixes back to the mainline where we have continued to develop new functionality for next year's release. The branch stays in our repository forever.
The way TFS does its branches is by having a new "folder" in the source control, and it is starting to get a little cluttered.
Thoughts:
Maybe the way we are doing this is right, but it just feels like in a few more years there will be a large number of branches that are never going to be touched... seemingly ever. Maybe it is possible to create a single "Stable Release" line that has each new version labeled on it, and then if we need to go back to do a mid-year release then it can be recovered from this single line.
Upgrade your environment to 2010 ASAP - TFS 2010 branching is vastly superior, including management.
Your idea sounds about right - you branch off a release version when you have one, then just fix it.
You just have to live with the versions accumulating. This makes sense - until you totally retire one (and "never" is not real here, I bet after 7-8 years you kill an old version) there simply is no other way.
A few places I have worked would handle that like this:
Devs never touch "main" branch directly and it always represents what is in production
A single "maintenance" branch is used for all of your changes throughout the year.
At the end of the year, after all of the changes are ready to go, label everything approprirately and the maintenance branch is merged back into the mainline. A new release build is prepared from the mainline and sent out.
Ongoing changes happen in the maintenance branch.
Rinse and repeat as needed.
Benefit is that you only ever have 2 branches. That makes some SCM related tasks easier to deal with since you don't have to keep dealing with changing folder names, etc.