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

vss to svn – 7 steps to svn goodness

Using Subversion for source control is all the rage these days. Everyone’s doing the svn dance. In fact, my most popular blog posting is about vss to svn migration, so at least it’s a hot topic here anyway. I assumed there’s lots of people making the switch out there, and figured I’d write up a few things to think about if you’re considering the move.

Why subversion? Mostly because svn just works. It’s a great little tool for doing what you’d expect of a solid source control system. It’s lightweight, so you can use it just about anywhere. Also – it’s free, which is always nice. There are plenty of other options out there, and each have their merits. This particular post is about the journey from vss to subversion.

1. Why? Are you sure?  Switching source control systems can be a real pain, especially if you’ve got a boatload of source. It’s definitely worth the effort in 99% of the cases, but sometimes the payoff just isn’t worth the disruption. If you’re a heavy Microsoft shop for example, you might want to consider jumping in with both feet and just moving on to the whole Team Foundation thing.

That being said, subversion rocks. Use it. 🙂

2. Preparing the new repo – You’ve got to install subversion somewhere, and create your new repository.  You’ll need to decide if you want to use the svn: or http: protocol to access your repo remotely, most people just tunnel it thru apache over http:.

You’ll want to start off with a nice clean, standardized layout for your new repo.  A safe bet is to use the old “trunk, tags, branches” route, with some default dirs in place (src, web, db, qa, lib, whatever).

If you’re not sure about installing/hosting it yourself, there are a handful of places that’ll do it for ya (dreamhost, cvsdude, … )

3. Exporting the stuff from vss –  The trick here is to do it cleanly.  You’ll most likely end up needing to delete all the .vssver files and whatnot.  Also, decide if you really need the entire history of files in your new repo… that could get hairy. Migrating to svn AND keeping all of your checkin history intact in svn is outside the scope of this posting. We decided we didn’t and kept a backup (read only) copy of the old vss db around “just in case”. You know, in case we ever needed to refer to something 3 or 4 years old.

Guess what? We never looked back. 🙂

4. Importing the stuff to svn – This is where it can get fun.  You’ll want to map your existing vss repository’s directory layout to your shiny new one. I ended up using a little perl script to get them all added into svn correctly. (vss2svn.zip)

5. Updating other various things and people –  You may have some existing systems already pointing to your vss repo, make sure to list them all out and get em updated. We had a handful of build scripts that needed to be update to point to the new repo.

Also, be sure to communicate effectively to your team. You might even need to do a little PR for the effort, so make sure you’re clear on #1 above. Provide your users with ample docs and support info to make the transition easier. Maybe host a couple “svn how to” sessions, to get things moving.

6. Testing This needn’t be too complicated, just walk through a handful of typical use cases. For example, do a few svn checkouts, make sure you can connect and everything’s cool, try a build or 2 from svn, etc.

The key here is to find and address (or figure out workarounds to) the most likely issues, and be ready to help your users get around em.

7. Relax and have a beer You’re off! Now just relax, watch your source get modified, and start forgetting about “vss analyze and fix”

🙂

VSS to SVN – How To

I wrote up a simple doc for my team to help smooth the transition from VSS to Subversion. Here’s the text of it, maybe it’ll help you too!

What is SVN?
Subversion (SVN) is our new version control system that is very similar to CVS. It fixes many bugs and limitations of the current version of CVS. We have chosen SVN as their version control system and have installed the SVN server on <your server here> for production use.

How can I connect to Subversion?
There are several open source Subversion clients available on the internet. There is a pretty long list of svn clients and plugins available. The quickest and easiest client to use is TortoiseSVN. For the remainder of this document it is assumed that TortoiseSVN is being used. The following steps outline the process for connecting to the svn server:

1. Download and install the Tortoise SVN client. It can be downloaded at http://tortoisesvn.tigris.org.
2. Install using the default settings.
3. Checkout the project that are interested in checking out.

Note – if you are working on drive over a network, you‘ll need to update a setting in TortoiseSVN to get the icons to show up: Go to Settings -> Look and Feel -> Icon Overlays and check the drive types for which you want to see overlay icons.Be aware that enabling overlays for network drives will slow down TortoiseSVN.

SVN Directory Structure
The following is the current directory structure:

https://your.repo.url – Doc root for production subversion repository

/applications – a listing of all current apps in the repository
-><appname> – application name
—>/branches – space reserved for development branches
—>/tags – space reserved for tags
—>/trunk – the main development line of code/db – folders for each database’s SQL scripts
->/<dbname> – database name
—>/branches – space reserved for development branches
—>/tags – space reserved for tags
—>/trunk – the main development line of SQL scripts/documentation – space in the repo for storing docs requiring revision control –>/<project name>
->/qa – space in the repo reserved for storing QA-related docs and scripts

It is possible to have other directories under the trunk for other requirements. For example, if a prototype is required for the project, a /prototype directory can be created for this purpose. Similarly, other directories can be created on an as needed basis.You may have noticed we’ve separated out the documentation from the source code. There are several reasons for this:

1. Isolating source from docs is generally a good practice
2. We’d like to reduce user/permissions management overhead
3. We plan to move as much documentation as possible into a document management / collaboration tool in the near future.

We’re trying to maintain a similar tree to what we’ve used in VSS, and make changes only where it makes sense.

Checking out a project
To check out a project from svn using TortoiseSVN, click on “File – SVN Checkout”. Enter the URL of the directory that you would like to check out and the local directory to put it into. For example, to check out app “foo”, the URL would be:

https://your.repo.url/applications/foo/trunk/

Simply enter your password when prompted and the download will begin.

Importing a new project
To import a new project using TortoiseSVN, using the Windows file browser, go to the directory above the one you would like to import and verify it meets the directory requirements specified above under the /trunk directory. Click on the directory to import. Click on “File – TortoiseSVN – import”. Enter the URL of that you want the directory to be imported into. For example, if you are importing a directory called “foo”, the URL to use is:https://your.repo.url/applications/foo/trunk/

Once the file(s) is imported you need to do a checkout to get the project back out of svn so that you can now modify the files.

Transitioning from VSS to SVN
Below are some common tasks we’re used to performing with VSS, and their equivalent in Subversion. SVN does some things fundamentally different from VSS, so it’s not exactly a 1:1 mapping, but this can serve as a guide during the transition:

VSS Command	SVN Command	Difference
GetLatestVersion	Update	The SVN and CVS update will notify if files are pruned from repository so you can remove them from local repository (VSS would not).
Add	Add	Even though they have the same name, there are very big differences. The VSS adds the file directly to the repository whereas in CVS and SVN it is a local note that is made. The file is only added during the commit.
Delete	Delete	Same as add but for delete
Checkin	Commit	These commands pretty much do the same
Checkout	—	There is no edit in SVN, but there is a lock command to lock a file before using it.
—	Checkout	The checkout in SVN is essentially telling SVN “I want to track changes in these files”. You do a SVN checkout when you want to initiate a project.
Undo Checkout	Revert (and unlock if necessary)
ShowDifferences	Compare	In SVN, you need to view the log for the file, and select 2 rpevious revisions. Then you can right-click and view diffs
Label	Copy	A tag in SVN is actually a copy. Therefore it must be copied in the tags section (see previous explanation).
(manual copy)	Copy	In VSS dragging and dropping a branch was the equivalent of a “branch”.

Where to find more information:
More information on Subversion can be obtained from the subversion book.

VSS to Subversion migration

Sorry for the dearth of posts lately, I’ve just been having too much fun with Subversion to post. Bad Release Guy! That, and about a hundred releases or so…
🙂

We have finally *officially* decided to use SVN, rather than Perforce. I’m actually pretty happy about the decision, I’m finding SVN to be a nice, simple, straightforward source control system. It doesn’t have all the “bells and whistles” associated with Perforce or ClearCase, etc., but it is a solid tool and does what a good version control system should.

The setup and install was pretty trivial, not a big deal at all. The only remaining item is to tie this thing up to my local authentication/authorization system. It’s proving to be more of a pain than I had hoped, and I’m not thrilled about just using SSH or Apache’s basic auth to control access to our repository.

I’ve put together some VSS to Subversion migration scripts (in perl) that have worked out quite well. It’s basically just a simple “get latest and add to SVN”, no labels or file history or anything gets moved over, but I’ve noticed the “VSS way” of doing things is not exactly based on best practices anyway. So we’ll just keep our old, VSS repository around in the meantime in read-only mode, in case we need to do some historical reporting.

If you’re interested in checking out my VSS to SVN migration scripts, have a ball!

Subversion everywhere…

OK, so maybe we won’t use Perforce.  A mischevious consultant casually mentioned that a lot of his clients use Subversion, and essentially recommended that we use it too.  So now the management types have decied we need to evaluate and consider Subversion.  Fun.  We’ve been evaulating source control tools for about a year now, and we were sooo close to finally actually making a decision.  But alas, the saga continues.

It looks like Subversion is basically CVS with some improvements.  It’s all open source, which I suppose is kind of neat.  But along with open source comes all sorts of fun little troubleshooting.  At least with a commercial vendor, they’ll help us get things set up, and support us if we need it.  Of course, that kind of thing comes with a hefty price tag, and, well, you know, it’s not like our source code integrity is really a big deal or anything.  Certainly not worth spending a few grand to make things better.  Nah…

Also, the other fun thing is trying to figure out how to get our stuff from VSS into Subversion, while keeping all our labels and history and all that jazz intact.

Well, the good side of all this is:  we’ve thought this thing through to death, and whatever we do decide on, we’ll never be able to go back and say “oh, why didn’t we consider that?”.  It never hurts to be thorough when choosing a toolset you’re planning to have for years and years to come.

Goodbye VSS, Hello Perforce!

It looks like we’re finally gonna get off of VSS entirely and just move on over to Perforce.  Yay!  I’ve never actually used Perforce, but from what I’ve heard and read on their site, it looks like it’s gonna be sweet.  Plus, just about everyone who’s anyone is using Perforce or CVS, so it can’t be that bad.

Gonna hafta start mapping out the migration path from VSS to Perforce.  Looks pretty straightforward, especially since they’ve been kind enough to provide some VSS to Perforce migration scripts.

More later, gotta go watch the Shield.

VSS 2005 Upgrade

So while we’re trying to decide what do do with source control long-term, we figured we’d take VSS 2005 for a test run – just to see if it’d hold us over for a while. 

The main thing we’re missing right now is access over http for our remote crew.  Sure there are some nifty tools for VSS over http, but VSS 2005 has it built-in.

The good: VSS 2005 client sure is purty.  It’s definitely a little slicker, and the branching/merging seems a bit smarter (it couldn’t get worse, right?).  Seems to run faster too, which is nice.

The bad: Turns out, you need to use the latest VStudio (2005) client to access the repository over http.  Pretty lame, you’d think you could at least just use the VSS client.  I suppose since it’s really just exposed as a web service, someone’ll make a better interface to it, but I haven’t seen it yet.

The ugly:  Took me about 3 days to get the darn thing runnin.  For some (as yet unknown reason), VSS and IIS just would not play nicely together.  After a couple days and a few unfruitful hours on the phone with MSFT techs, I decided to just install it on another machine (an IIS box built to the same specs as the first one, just without anything on it yet).  20 minutes later it was up and runnin… go figure.

Which source control system?

So we’re thinkin about getting off of this clunker VSS.  Sounds like MSFT is plannin to phase out VSS as a stand-alone solution, and bundle it in with the VS Team Foundation suite.

In doing some research and product comparison, it looks like PerForce is the way to go.  Anyone have any thoughts/tips about migrating source control systems?  Sounds like it’s gonna be a fun one!