Randomly released code for life. How to prevent recurrence?

Question

We recently had an incident where some code for life was released that should not have been released.

He was obviously checked in the trunk. Which is good, I assume that you want to check earlier, check often .

However, in this case, it should not have been released in the next version.

What checks / strategy / process can be implemented to avoid premature code failure.

It seems to me that even with continuous integration and unit testing, is this a human procedure problem?

- Lee

Answer 1

Change integration procedures.

If “going to live” means that someone is executing some batch of script - do not be surprised if this happens again.

Also consider branching. A common example would be to use a trunk for development, a separate branch for testing (for example, merges once a week), and a final branch (from the aforementioned test branch) for RTC.

This branch must be thoroughly tested before being deployed to production.

Answer 2

You must have different branches if the version control software allows such a thing.

In this case, you will have a person who is responsible for merging the code that has already met the quality barrier from the main branch to the production branch.

---

UPDATE: Despite the specifics of the product, the guide available in TFS 2008 Branching Guide 2.0 contains many recommendations that can be applied to other version control software that has the ability to create branches.

Answer 3

Do not create for production from the connecting line - manually compile the code of the connecting line into the production branch and proceed to this. Or, as the other answers say, use any number of branches and steps in the testing procedure that suits your needs.

In addition, code changes that take more than one day or so should usually be done in a separate property branch until this is done.

Answer 4

The problem, obviously, is not checking the code in the repository. Here you have two problems:

1) Any code that should go live must have a special version tag or branch or something else, depending on the control you are using. So live code never gets confused with code in development.

2) Who is the moron who puts an unverified code anyway? There is a serious lack of communication if the person who put it live thought that your development code was ready for production.

Answer 5

To continue the discussion of branching, this is a way to preserve the version processing structure.

We use the connecting line as the main branch, and when we reach a certain point in the development cycle, where we are not allowed to fix more functions (only fixes), we insert the NEW branch for this version (instead of going through rapprochement with the error), and This branch is well tested before we leave it. Of course, for this it is necessary that every programmer should clear the commit when the function fixation date approaches.

Answer 6

It seems to me that even with Continuous Integration and unit tests is a problem with the human procedure?

Really! However, you can get some support from your infrastructure to support the human side of your process. When you are about to release, you can easily see all the commits that would be part of this, and all the problems associated with it. This is the reporting side of continuous integration. (I would say that there are four elements (pdf): creation, deployment, testing, and reporting.)

Answer 7

What checks / strategy / process can be implemented to avoid code released for life prematurely.

I would say that any process that does not have a check in the trunk as a familiar development ritual, which means any development model, except for cowboy coding.

Let the developers sooner or later go into their branches of signs and combine them in the body when the time comes.

Answer 8

We have created a release manager that works with subversion. www.ReleaseManager.com This way we can control what is released by the problem number (or error number), and we have control, so we can get things out of release when necessary. We are looking for beta sites now :)