JKI

I’m terrible at remembering important details.  I’m great at relatively useless stuff, like powers of 2 and the lyrics to songs my parents used to sing.  I even remember the phone number of a girl I had to call once in fifth grade, to get homework from her because I missed school that day.  It had two consecutive zeroes in it, which I thought was cool.  Come to think of it, I should see if she’s on Facebook.  Anyway, my point is this:  I forget stuff that matters.  One example of something I forget, which matters a lot, is how to build my customers’ applications.

That’s why I create a one-click build VI for every project.

The idea of a one-click build VI is that anyone should be able to check my code out of SVN, open build.vi, hit Run, and build the application (or the VI Package, or whatever).

Example One-Click Build VI (Front Panel)

Some smart people whose work I respect are big on this, and a one-click build VI offers several immediate advantages as soon as you start using it:

1. It helps you document your build process,
2. It makes it easy to build early and build often, and
3. It lays the foundation for other good software engineering techniques.

I’m going to elaborate on each of these items, and then at the end I’ll show you how easy it is to get started with your own one-click build VI.

1) It helps you document your build process

For complicated applications that have multiple, separate pieces, an automated build is essential.  But even for small projects, the cycle of releasing an application can be surprisingly long:

1. Build the EXE.  …and wait for it to finish.
2. Build the Installer.   …and wait for it to finish.
3. Find the installer on disk and zip it up.  What’s the convention I use for naming the ZIP?  Oh, yeah, I remember.
4. Upload the installer to the FTP site.  What directory does it go in?  Oh, there it is.
5. Copy the installer ZIP to the archives. Where are those archives again?
6. Commit the project file to SVN, because the build process modified it.  Did I do that already?  Maybe after #2?  I don’t remember.  Oh, OK, I already did that.
   

The point is that even for simple applications, this process is long and error-prone, and you should write it down so you do it exactly the same way every time (because you’re a good engineer, and you care about repeatability).  So if you need to write it down anyway, why not write it in code?  Then, those 6 steps above collapse to

1. Open build.vi and click Run.

That makes it easy for you to build your app whenever you feel like it.  How about over lunch?  Or when you leave your desk every night?  Or during that otherwise time-wasting meeting with your boss?

Not only that, when you use a one-click build VI, anyone can build your app exactly the same way.  It decreases the amount of tribal knowledge in your organization, because the build process is captured in the code, even if code itself is terrible (have you considered the JKI State Machine?).  Decreasing tribal knowledge is important because you might get hit by a bus.  Don’t laugh, it happens.

Example One-Click Build VI (Block Diagram)

2) It makes it easy to build early and build often

If your build process is easy, you’ll want to build your application.  Or looking at it another way, if your build process isn’t easy, you won’t want to build your application.  We already know that it’s a good habit to build your EXE on day one, and keep it working.  But building is a mental context switch, and it takes you away from whatever other really important stuff you’re doing.  That’s why the act of building your EXE should be so trivial that it’s kind of fun.  Opening build.vi and clicking Run is pretty fun, as far as crummy, repetitive tasks go.

3) It lays the foundation for other good software engineering techniques

A one-click build VI is a type of automated build.  And an automated build is a core piece of a successful continuous integration system.  But continuous integration isn’t just for big companies with big products.  Imagine if you had a one-click build VI for your project, and you set it up to run every night at midnight.  Then you could come to work every morning, and a shiny, brand-new build of your current app would be waiting for you to test.  Or, if the build is broken, you’d know it immediately.  This allows you to have trust in your system, and in your software, throughout the development cycle.

OK, so how do I make a one-click build VI for myself?

The VI you see above is a typical one-click build VI for a project with an EXE and installer, built using NI’s application builder in LabVIEW.  It also includes some ancillary features, like zipping up the installer, making some changes to the project file XML, and committing the modified project file to SVN.  It incorporates some switches so I can enable & disable some of these features as required.

But you don’t have to go to that level of detail to get started with a one-click build.  NI gives you everything you need:

BuildTargetBuildSpecification.vi from vi.lib

The VI highlighted above is located on your system at <LabVIEW>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi.  NI has a couple of reference pages on the topic here and here.  You pass it your EXE and/or installer build scripts as shown, and in seconds you’ll be on your way to forgetting everything about how to build your customers’ applications, just like I have.

In the future, I’m going to talk more about specific ways you can use a one-click build VI in your projects.  In fact, I’ll probably write those articles while a one-click build is running in the background!