Release Management

1) What factors influence the opening of a feature branch?

Typically, feature branches are created in cases where the new feature or enhancement has broad-sweeping changes to the code base such that introducing them in the trunk may be too disruptive. Also, feature branches may be used for prototyping or proof-of-concept for code that may never end up in trunk.

2) What is the purpose of continuous integration for a development team?

The primary purpose of CI is to provide regular, fast feedback to developers as they commit changes to the shared code repository (VCS). The idea being that we’re always integrating our code on commit, so that when conflicts arise, they can be addressed more quickly and easily than if the changes had been made days, week, or even months ago.

3) Describe a branch structure for a highly iterative web product?

A common branching structure would be as follows: one primary line of development, called “trunk”.  All iteration work should be done in trunk, except for cases as described above where branches are appropriate.  For those cases, a private/feature branch is created, and the “owners” of that branch take responsibility for merging trunk into said branch periodically (at least weekly, maybe more, depends on churn/code change volume) so as to avoid too much drift.

Upon completion of the initiative which required a branch, those changes are merged back into trunk in time to perform regression testing ahead of the next production release.

Prior to production release, a “release branch” should be created.  This is effectively the “release candidate”.  Access to commit to the release branch should be limited and relatively controlled. Any changes made to the release branch should be merged back into trunk as well.

Builds, deployments, and regression testing should be performed against artifacts built off of the release branch.  After successful release (“go-live”, “launch”), the branch gets locked down again and is kept around in case a high-sev bug is found in production and needs to be fixed asap.

4) Describe a set of release criteria for web calculator application?

Release criteria is fairly subjective and varies a lot depending on the organization and the app.  That being said, software should not be released without the following:

• an understanding of the purpose of the release
• all high severity bugs closed or deferred
• release notes with a list of detailed fixes/enhancements (bug #’s perhaps?) and instructions for any server config or settings changes
• sign-off from a QA person (preferably some type of “lead”)