I come to the office in the morning, start Visual Studio and fetch the latest versions of the source code....recompile
the solution: COMPILATION ERROR. The build is broken! That's for sure something you don't want to see in the morning!
in a team is actually not that straightforward. Normally (actually there should be!!), there is a version control
) in place which allows more people to work
together on a project. But that's not enough. People need to be aware that they're not working alone on the project and
have therefore to use the version control system appropriately. "Of course" you would think, but it sometimes doesn't
seem that clear to people.
The number 1 rule: NEVER EVER
upload a broken
build to the common repository!!
Why that?? Well, because the next time your team members are fetching the latest
versions, they'll have a broken build on their local development environment, which will not allow them to continue to
work on the code.
Don't get me wrong, it's not that it never happened to me that I accidentally uploaded some
broken build. Anyway, I started to think about some guidelines for working with version control systems, lets call them
- ONLY check-in working code
Checking-in or committing only working
code is essential. If you don't do so, you'll break the build.
- Check-in often
Don't check out in the morning and check-in in the
Checking-in in short time frames has several advantages. For the first you have always only checked
out the code you're currently working on, which helps you keeping the overview and secondly checking-in is somehow
a backup of your work. Lets assume the case that you've implemented something wrong or you made a mistake which
broke your whole build. If you checked-in constantly, you can just revert to a previous version.
So the advice
is: implement a use-case (if it isn't to large) and after successful implementation commit it to the repository.
- Fetch the latest versions regularly
It doesn't cost you anything!
Retrieve the latest source code versions regularly to stay up-to-date. Assume you're working on a piece of code
which makes use of functionalities provided by other source-code modules which you're not currently working on.
Those functionalities may change while you're working on your code. Method signatures may change which may break
your running-code. By fetching the latest version you can immediately react to those changes.
- Write comments on the files you check-in to the repository
this may be annoying, but it may help you, especially when there comes the situation when you have to revert to a
previous version. Then comments may help you find the right one.
So how could an ideal work cycle look like(from my perspective)?
- Open your programming environment and fetch the latest versions from the repository
- Compile and build the system to see whether there are no problems.
- Check out the files where you have to work on and implement your use-case.
- Once finished, make sure that everything compiles without errors.
- Again, retrieve the latest versions from the repository.
- Run a project build to see whether still everything compiles and works fine.
- If it does so, check-in your changes and add a comment to what you've done.
- (Continue with step 3)
I'm actually not an expert, but if you follow these rules, everything should work fine. The steps mentioned above
are somehow adapted to the work with Microsofts TFS (Team Foundation Server) where the option of multiple checkout is
disabled. This easies the handling because code merges should theoretically not be necessary. If you're working however
on SVN systems where theoretically two team members could work on the same piece of code at the same time, things
become more complicate and need still more discipline. In that case before you commit, you're usually doing a
synchronize with the repository. You'll get a list of conflicts which you have first to solve by manually merging the
files and fixing your local build. Once that is done you can commit your code.
So happy coding ;)