I work with a team of programmers as the business analyst. We just released version 2.0 of our product and are working on the next version to be released in 3 months (it’s an internal software product). Unfortunately version 2.0 has some issues that they have had to fix and we’re going to deploy those fixes in a couple weeks. The problem is that we also don’t want to deploy the changes that are still being worked on and are not slated to be released for another 3 months.
The programmers decided that the way to manage this was that only the code for the defects will be checked in, and the code for the new enhancements will be kept on the developer’s local machines until they are done. I will have to get local builds from their machines to test because if they check in the code and we have to push out another patch to fix defects we don’t want to include those enhancements just yet. There is also the problem where the same code file contains both defect fixes and enhancements, so they have to copy the code file locally, then make a change to fix a bug and check that one in, then resume work on the enhancements by taking the local copy they made.
It seems quite convoluted – is there a better way to handle this type of scenario? We’re using Team Foundation Server and Visual Studio 2010.
20
V2.0 should have had what we used call a ‘steady-state branch’ (we used Perforce, not TFS) made for it once it was released. Any fixes for v2 would have been made to this branch and then propagated back into the v3 development branch while v3 features were also being worked on, i.e. a defect on v2 would result in a defect also on v3.
Having changes reside on developer’s machines for a long time will likely result in an integration nightmare.
3
Well there are multiple ways to deal with issues like that, generally covered by ‘branching’ tag, each with own set of benefits and downsides.
But approach chosen by your developers… gee I’ll quote it verbally to make sure that I didn’t misread…
code… will be kept on the developer’s local machines until they are done…
…the way like above is probably the only one that is totally, completely wrong!
What makes it border to criminal to me is that for TFS, there is an excellent, easy to understand, Microsoft Team Foundation Server Branching Guidance – huge and detailed document with branching strategies recommendations carefully tailored and explained for all kinds of different projects (HTML version here).
2
- Your dev’s have a fundamental misunderstanding of how to use version control.
- Do not get into a discussion about the “right” version control software. This is not the problem.
- Every code tweak is making the problem harder to fix.
- WHEN y’all decide to do the right thing, you cannot continue code changes while you fix things. You MUST stop all development and get the code into version control.
- The dev’s must be feeling the pain enough to at least sit down and talk about it.
- All version control software supports basic concepts:
- ALL code goes into the version control repository.
- All code files have version numbers. These numbers increment automatically as code is re-checked in.
- A TAG marks all code files of a (and at a) particular version. Thus we can TAG the software version 1 release, for example.
- a BRANCH is a “turn away” from the main trunk.
- Any and all changes made to a branch do not affect the trunk.
- You may optionally merge branch changes back into the main trunk at some point.
- Thus we may experiment without fear of messing up “the good stuff.”
- Y’all must get the version control “leap of faith” as I call it. TRUST that following basic rules will keep things straight. Inexperience makes us think otherwise, trust me.
- Here is a decent tutorial. It is general and complete enough that you don’t need to scour lots of other sources
- Version Control, Better Explained
edit
- Put version control on your work computer.
- You can do this right now w/out team coordination
- Even with team version control, I highly recommend this
- If your team uses Git or Mercurial you are using an independent, local repository. That’s how distributed version control works.
- You can use different VC software from your team. Our team uses Subversion, I use Mercurial locally. The VC software metafiles (“.svn”, “.mg”, hidden folders) do not conflict.
You are not acting as a de-facto team repository. It’s for managing your own work, refactoring efforts, etc. and CYAing yourself as the team continues to FUBAR the code base.
end edit
2
What you are describing is a terrible way to use version control. There should have been a branch made for release 2.0, or a tag or some identifier. That way, modifications to that release can be contained and more development can continue to happen.
This article can give you some ideas. It’s written with git in mind, but there’s no reason that it couldn’t work with mercurial as well. I realize that you’re using neither of these, but that’s also a problem that you should consider fixing.
8
Quick Answer: Development team should have a separate Production branch to keep deployed code-base V2.0 separate from the Main trunk.
All the bug fixes need to be done in that branch first and then tested and deployed to other branches, in order to keep code in sync.
Your project should also have have several environments for health development like Prod, Staging, QA and Dev (sometimes UAT ). These environments should be set up before going to Production release.
All in all, being ready for bugs and modification is the way to support a released application.
As TFS was mentioned as a version control, i have also compiled list of articles which will be helpful to set health development environment(s):
- Implementing Team Foundation Server with a small development team
- Welcome to the TFS Integration Platform!
- Team Development with TFS Guide
- Setting Up a Development Environment
No, because while you are using a VCS, you are not doing version control.
The central concept for version control is tracking difference over time, you are PLANNING on recording some differences, but at the moment most of your changes are unrecorded.
As others have said, you should be using branches. Once you have that setup, you should be checking in all functional changes (ie not every keystroke, but anytime you fix a bug, add a feature, delete a feature or otherwise complete a change such that it still builds and works).
I’m a developer and we are given different branch code and db for fixes of current version and a different for enhancements and for later consecutive version.
Once our fixes are done they are merged with production and are deployed we get new fresh branch to work again back to enhancements.
Moreover we follow a practice like if I have 10 fixes for my current version
I write as
//Start Iteration 2, Fix No-1, Branch No-"ABC"
code where I have done changes or fixes or added new code lines
//End Iteration 2, Fix No-1, Branch No-"ABC"
Similarly for other fixes, I just do this for each and every line I change or add for fixing. And just compare and commit. Similarly if they were doing parallel on same branch they can use
//Start Enhancement -1, Branch No-"ABC"
code where I have done changes of fixes or added new code lines
//End Enhancement -1, Branch No-"ABC"
Ctrl+Shift+F command and type //Start Iteration 2, Fix No-1, Branch No-"ABC"
to search in entire solution helps a lot to find out exact locations, files where code is changed and take fresh code only that part can be used to commit.