Meetup talk on CI

I presented an overview of CI in the enterprise at last week’s Large Scale Production Engineering meetup.

It’s been posted on slideshare, check out CI In The Enterprise: Lessons Learned!

Build Engineer interview questions

An actual e-mail with interview pre-screen questions about build and CI.  Note the answer to #7, classic!

Release Guy,

Below are the eight prequalifying questions that <name removed> requested you answer.

1. What factors influence the opening of a feature branch?
2. What is the purpose of continuous integration for a development team?
3. Describe a branch structure for a highly iterative web product?
4. Describe a set of release criteria for web calculator application?
5. When are you available to start a new position?
6. What are your top 3 strengths?
7. What are your top 3 weaknesses?

>>>>>>>>>>>>>>>>>>>>>

Hi Ms. Recruiter chick,

Please see my responses below:

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”)

5) When are you available to start a new position?

6) What are your top 3 strengths?

Communication/collaboration, ANT scripting, troubleshooting/optimizing Java builds

7) What are your top 3 weaknesses?

I, like Chuck Norris, have no weaknesses.

Thanks,
Release Guy

Quick Build

In my search for an effective tool for managing builds and releases, I’ve decided on QuickBuild.  It’s basically a commercial version of LuntBuild, with some nifty management features added in. 

One of the nicer things about it is the ability to set properties for an app, and have them propagate to different configs for that app (dev, QA, staging, UAT, production), while having the ability to override certain values (say, DB username and password, etc…).

Like CruiseControl, it works well for continuous builds when integrated with your source control system.  Subversion and QuickBuild work together quite nicely.  Though, unlike CruiseControl, QuickBuild allows for “on-demand” deployments, and it’s promotion management features make it a cinch to migrate code from dev -> QA -> staging -> produciton.

I’m currently adding my apps to QuickBuild, and I’ve found it to be really easy to setup, use, and manage.  The end goal is to automate as much of the release process as possible, allowing for more predictable, repeatable, and consistently “problem-free” production releases.

Plus, it certainly would be nice to be able to release apps remotely via a web-based interface.  Now, if I can just figure out how to access QuickBuild from the golf course…
🙂