Tech Startups 101: The One-Click Build

by on

Editor’s Note: This post was originally published on Seattle 2.0, and imported to GeekWire as part of our acquisition of Seattle 2.0 and its archival content. For more background, see this post.

By Anthony Stevens

This is the fourth in a series of posts on the “tech” in “tech startups”.  The earlier posts on source control, continuous integration, and cloud computing are not required reading for this post – each stands on its own – but they may be helpful to get some additional background on some of the terminology.

Today’s topic: The One-Click Build.

(waits for angels and harps and kazoo-tooting unicorns)

The One-Click Build, hereafter referred by the acronym OCB, is a sort of holy grail for software development teams.  It allows you to, with one click, build ALL of your software, and deploy it ALL to the proper location.  I’ll get into details in a moment, but let’s talk about why this might be important to tech startups.

First and foremost, it increases your agility, where agility is defined as “how quickly can you respond to a new customer request or market opportunity.”  There are a surprising number of steps involved in deploying even the smallest real-world software systems.  If you don’t have a OCB in place, you have to do these steps manually, and it takes time.  Every time.
However, if you DO have an OCB in place, you can deploy more often, because everything is automated.  For most high-frequency iterating tech startups, this is a very good thing.
Second, it decreases your risk.  Nobody likes egg on their face, least of all hard-working startup types for whom the adage “you never get a second chance to make a first impression” is ruthlessly applied.  If you’re doing a manual build, with an individual making decisions at each step about what to get from source control, what to compile, and where to deploy it, you’re taking on a lot of risk, and you may push a bad build out at just the wrong moment – say, when a key customer is making a purchase decision.  You want only good builds.
Further, if that individual suddenly leaves the company, the critical question of “how do we do builds” may, all of a sudden, lack answers.

What’s involved in setting up a one-click build?

First, list out (or better yet, diagram out!) the various deployment scenarios.  This typically will involve some or all of the following components:

  • Source Control systems
  • Build servers
  • Websites
  • Web services
  • Databases
  • Batch jobs / cron jobs / scheduled tasks
  • Files / other file-based resources
  • Server configuration parameters
  • Security parameters
…  and that’s not all.  Your situation will be unique, and you’ll have your own set of components.
The workflow for an OCB typically goes something like this:
  • Get the raw source code and files from the source control system
  • Build/compile the source code
  • Run database scripts against your target databases
  • Configure the target environments with whatever configuration parameters you need
  • Deploy the software to your target environments (ex: websites)

This is, again, a simplified list.  But it’s a starting point: GET->BUILD->CONFIGURE->DEPLOY is a useful sequence to keep in mind, I think.

The OCB itself is typically a script, written in your scripting language of choice, that in turn calls other, specialized scripts to do each of the steps required. All of the steps required in an OCB, such as “Run this SQL script against this database”, are scriptable.  All of them.  If you don’t think so, check again.  It may be hard, but it will be scriptable.

Downsides to an OCB?

The first, and most popular, is the notion of fragility.  Every time your target environment changes, you have to change your OCB script(s).  For example, if you have to start pushing new .mp3 audio files out to your web server, you’ll need to alter your OCB to accommodate that.  I answer this concern by pointing out that you’ll have to do the new build step somehow – why not automate it?

The second (less obvious but more problematic reason IMHO) reason is security.  Your OCB scripts will either (a) include usernames and passwords for the target environments (bad! bad!) or (b) require the OCB user to enter in the security parameters when the run the OCB script.  If you have several target environments (website, database, cloud environment, e-mail server, etc.), and you’re deploying multiple times per day, the temptation to put the usernames and passwords in your script will be overwhelming.  This issue is a thorny one.  One possible answer is to hash passwords in some file that you include in your build process, but a lot of the scripting targets can’t make use of scripted passwords – they expect plain-text, or worse, interactive passwords.  Do the best you can here, and be aware of your exposure.

The third downside has to do with psychology. The truth is that nobody gets it down to one click.  Even the best, most talented, most enterprising software development teams have at least a few (scripted) steps in their deploy process from time to time.  So, the thinking goes, if one click is out of reach in practice, why kill yourself to try to get there?  I like to respond to this one with the metaphor of eating healthy foods.  It’s a worthy goal, and the better you do at it, the better off you’ll feel – but everyone slips up now and then, and nobody eats perfectly well all of the time.  Again, do your best.

Would love to hear from you about your own build/deploy process, how many or few steps you have, and what your experience has been.  See you in the comments!

Like what you're reading? Subscribe to GeekWire's free newsletters to catch every headline

Job Listings on GeekWork

Find more jobs on GeekWork. Employers, post a job here.