version control practice

Question

In my current job the supervisor's practice is to only check in production ready code. Most recently the project I was on involved work by 3 different developers with some file overlap. This meant manually integrating changes despite the fact that some changes took a day and then it was done. I wanted to see if this was a common practice and get suggestions on how to change this practice with the knowledge that many times my opinion means little in the grand scheme of things.

Answer 1

Code that is checked in should be unit tested, but, to me, "production ready" implies that it's gone through integration and system testing. You can't do that until a code freeze, so I don't see how you can do that before every check in.

Answer 2

I just asked a very similar question. It would be cool if we could link questions together somehow.

Answer 3

I would personally not approve of this because sometimes that's the best way to catch problem code with less experienced developers (by seeing it as they are working on it) and when you "check in early and often" you can rollback to earlier changes you made (as you were developing) if you decide that some changes you made earlier was actually a better idea.

Answer 4

wouldn't it be a good idea to have a testing branch of the repo that can have the non "production ready code" checked in after the changes are done and tested?

the main trunk should never have code checked in that breaks the build and doesn't pass unit tests, but branches don't have to have all those restrictions in place.

Answer 5

You can use various ways to handle this situation, depending on your source control system.

Private branches: Allow you to check in and work on code while you go, merging back and forth at appropriate times.

Shelvesets/pacakaged changesets: Allow you to store changesets and send them around for review - ensuring they're production ready before check in.

As to whether this is an appropriate way to work, we don't allow check-in to main branches without prior review. To pass review your code must pass various automated tools, and then must be acceptable to your peer reviewer. For some definitions of "production ready" - this is it. Therefore, we do something like what you do. However, we use private branches to ensure that check-ins can still be made while this is in progress, and that other check-ins don't have to interfere.

If production ready means tested in an integration environment, then it sounds like you may need staging branches or something similar.

Answer 6

I think it may be the version control we user, VSS in combination with a lack of time to learn the branching. I really like the idea of nightly check ins to help with development and avoid 'Going Dark'. I can see him being resistant to the trunks but perhaps building a development SS and when the code is production ready move it to production SS.

Answer 7

From the practices I have seen the term production quality is used as a 'frightener' to ensure that people are scared of breaking top of tree, not a bad thing to be honest because top of tree should always work if possible.

I would say that best practice is that you should only be merging distinct (i.e. seperate) functional components on the top of tree. If you have a significant overlap on deltas to the same source files I think this 'might' indicate that somewhere along the line the project management has broken down, and that those developers should have merged their changes to seperate integration branch before going in to the main line sources. An individual developer saying that they unit tested their stuff is irrelevant, because the thing they tested has changed!

Trying to solve integration problems on your main line codeline will inevitably stall other unrelated submissions.

Answer 8

Assuming that you are working in a centralized version control system (such as Subversion), and assuming that you have a concept of "the trunk" (where the latest well-working code lives):

If you work on new features in "features branches"/"experimental branches", then it's OK to commit code which is far from finished. (When the feature is done, you commit the well-behaving result into the "trunk".)

But you will not win a popularity contest if committing non-compiling/obviously non-working code into the "trunk" or a "release branch".

The Pragmatic Programmers have a book called Pragmatic Version Control using Subversion which includes a section with advice about branches.

Answer 9

Check in early and check in often for two main reasons -

1 - it might make it easier to integrate code

2 - in case your computer explodes your weeks of work isn't gone

Answer 10

@bpapa

Nightly backups of work folders to servers will prevent losing more than a days work.

@tonyo

Let's see the requirement documents were completed the day after we finished coding. Does that tell you about our project management?

We are a small shop so while you would think change is easy there are some here that are unbending to the old ways.

Answer 11

@Troels Arvin

I think we just sof'ed pragprog.com as I can't seem to connnect to it.

got one of these

Network Timeout

The server at www.pragprog.com is taking too long to respond.

The requested site did not respond to a connection request and the browser has stopped waiting for a reply.

• Could the server be experiencing high demand or a temporary outage? Try again later.

Answer 12

An approach I particularly like is to have different life cycle versions in the depot. That is,for example, have a dev version of the code that is where the developers check in code that is in being worked on; then you could have a beta version, where you could add beta fixes to your code; and then a production version.

There is obvious overhead in this approach, such as the fact that you will have a larger workspace on you local machine, the fact that you will need need to have a migration process into place to move code from one stage to the next (which means a code freeze when doing the integration testing that goes with the migration), and that depending on the complexity of the project(s) you might need to have tools that change settings, environment variables, registry entries, etc.
All of this is a pain to set up, but you only do it once, and once you have it all in place, makes working on different stages of the code a breeze.

Answer 13

Start by switching away from VSS to something more reliable & feature-rich. See How to convince a company to switch their Source Control

Then apply known-good practices:

• Check in often
• Pick up others' changes often, to simplify merging
• Use fast unit tests to make sure each change meets a minimum bar
• Require that that the checked-in code always builds, and always passes tests.

Now you won't be "production ready" at this point: you will still need a couple weeks to test & fix before you can deploy. Getting that time down is awesome for you, and awesome for your customer, so invest in:

• High quality automated acceptance tests.