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

Build and Release – a match made in heaven?

So I’ve taken to digging a bit deeper into the build side of things, so please don’t be upset if this turns into more of a build automation blog… It’s just where I’m spending a lot of my time lately.

I’ve started to see Release Management as a bit closer to the business side of things, and looking at what I do as more “build and deployment automation”. At my previous job (where I was when I started this blog), I did pretty much everything form managing SVN, to automating builds and deployments, to managing a bunch of servers. Since getting out of Academia and into the “real world” of business, I’ve noticed that these roles tend to be a little more separated.

Now that I’m consulting, I even made a little online resume thingie for your enjoyment – check it out!

http://www.justinlittle.com/

I am available for consulting too! Wouldn’t it be neat to be able to say you hired the guy who “wrote the blog” on release management? 🙂

Right now, I’m working on helping a small software company in Silicon Valley automate the heck out of their build. We’ve got a desktop app written in C#, and we didn’t really have any automated builds at all. It’s pretty cool walking into a place that has a clean slate, and being able to completely build out a system from scratch.

I can’t really say I love working with MSFT products anymore, I think I’ve gotten spoiled with the explicit and transparent nature of working with Linux/Java stuff. It seems like MSTF is trying to do everything for you, which is cool until things start breaking and you need to troubleshoot. OK, that’s my mini MSFT-bashing rant, I’ll stop now, I promise.

So Bill G and the Gang have some pretty interesting little tools together, most notably MSBuild in conjunction with Team Foundation Services. I can’t say I love it, but it does (sort of) work. I pretty much eschewed their whole solution, and just wrapped a call to MSBuild inside my ANT scripts, and then wrapped that in CruiseControl.NET for scheduling of builds and for email notifications on builds events. It all seems to work pretty well, the only real hiccup was getting ANT to play nicely with Team Foundation’s source control.

I just use the tf.exe command line client form an exec inside my ANT script, but it’s not pretty. Mostly cuz doing a “get” makes everything read-only (kinda like vss), and that doesn’t really work for me cuz the build actually produces some artifacts/shuffles around some files. Since I don’t really know what MSBuild is up to behind the scenes, I ended up just making them writable after “get”ing them using hte old “attrib” command. Weak sauce.

Other than that, CruiseControl.NET seems to be pretty happy. We’ve now got nightly builds popping, and all is good in the world. Now if I could only get my hands on a decent GUI based testing tool for WinForms, then I could run a handful of smoke/regression tests after the build happens, so we know we didn’t break anything…

A useful tip for variable substitution

Using QuickBuild for building and deploying apps is fun!  I’ve got 3 of my apps into QB now, and their build and deployment is almost completely automated.  I’m getting closer and closer to the Holy Grail of release management – the “magic button”.  You know, that button you push that just automagically a) pulls your code from the repo, b) builds and/or copies all dependent jars to the app local folder, c) builds (compiles and packages into a .war) the app and d) (the grand finale) automatically deploys the application to our Weblogic farm.

One thing we had to do (or rather, get the engineers to do!) was standardize on how we use environment-specific variables.  Obviously, for DB connections your best bet is to always use datasources whenever you can.  Then your apps just need to refer to those, rather than using database servername, db name, user, password, all that junk.  Not only does this streamline the migration from dev to qa to prod, but it also abstracts your database connection info, which is nice for several reasons (not the least of which is security).

But what about other variables?  What if your log location is different in dev vs prod?  Or what if you want to send error e-mails to a different address from qa vs prod?  You need to do some kind of variable substitution at build time.  Enter the .tmpl file.

Require (or ask, or beg, or bribe) your engineers to keep all of these “configurable” values in one file – typically an ApplicationContext.xml or something that looks like it.  Then, have them put the values for these variables in a properties file somewhere (app.properties or whatever).  The last step is to actually use a .tmpl file, and dynamically generate that .xml file using this instead.  If no values are passed through to the file from ANT or QuickBuild, then the app will just use the properties specified in the properties file.  But if you do want to pass them through at build time, all you need to do is create a variable for that config in QB (or ANT, if you’re not using QB yet!), and viola! – you’ve got the right stuff where it needs to be.

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…
🙂