Can You Build Your Application in One Click?

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

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)

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

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!

This entry was posted in JKI, LabVIEW and tagged , , , , . Bookmark the permalink.

8 Responses to Can You Build Your Application in One Click?

  1. Ton Plomp says:

    The thing missing from this routine is the possibility to change the build number of the executable and installer.
    LabVIEW 8.2 had access to these properties via some obscure resources VIs.
    Unfortunately with the rewrite to classes the API was totally dropped.

    Using auto-numbering is not very convenient. For an exe this is OK, but I can’t control it and have to rely on LabVIEW, and I can’t get the info available.

    Ton

  2. Justin Goeres says:

    Ton,

    That’s a great point A solution that I use is to have build.vi edit the XML of the project file directly to increment the build number (or set it to whatever I want) and then save the .lvproj. The only wrinkle is that this requires starting out with the project file closed. After the edits are done, build.vi opens the project file and runs the build script(s). This technique is on my list of “possible things to blog about,” so I’m glad you brought it up.

    Justin

  3. Dean Mills says:

    Hi Justin,

    This might not seem like it but this is a very important blog and most people won’t recognize the importance. I have spent the last 14 or so years building executables. Automatic building is the one of the best things to happen. The real question for everyone is how to use it to your benefit.

    At Meikle Automation we have been using a semi automatic builder since 2000, when I started. Once I found out that full automation was possible we created a fully automated builder. We automatically edit the project file to modify the build number. It runs every day whenever a developer needs a new executable.

    We do a few things a bit differently as we have a single software product for all project. We have a dedicated PC for building exe’s and compiling FPGA code. We access it through logmein, so we don’t need to be in the office to build a new version. We automatically update from svn. Our software builder includes all previous projects so old projects can be updated to the latest version. We have error reporting when a single VI breaks the build and success reporting when a build is complete. Those get emailed to the software team. We include things like build number, a html link to the ftp site it resides on and an extra message so other developers can know if they can to ignore this build or not. This is most useful when we have several people in the field and 1 person in the office fixing the code.

    The latest revision of our builder includes the creating an installer. This executes a few scripts that builds an installer. We have several other 3rd party installers that are required and NI doesn’t provide a nice way to build them into an installer

    The unfortunate side is we don’t have the excuse of “I am waiting for my code to compile” anymore.

    Dean

  4. Justin Goeres says:

    Dean,

    Wow, it sounds like you’ve got a great system set up!

    We’ve recently hit some pain points while building complicated installers using NI’s builder. It turns out it’s not always enough to just have the right code from SVN and the right reuse libraries installed — the installer builder wants junk from God-knows-which platform DVDs. It can make building installers on more than one machine an adventure, to say the least.

    Because of that, we’re looking at ways to solve the problem with a dedicated build system, as well. You can be sure we’ll blog about it, if only because it means bragging about sweet hardware.

    Justin

  5. jcarmody says:

    Justin,

    Is the JKI State Machine VI (above) available?

    Jim

  6. Jim Kring Jim Kring says:

    Hi Jim: No, state machine shown in Justin’s example is not publicly available. Maybe some day :)

  7. Pingback: JKI Blog · Jim’s Top 10 Features in LabVIEW 2010

  8. Pingback: VIPM 2012 Released | JKI Blog

Leave a Reply

Your email address will not be published. Required fields are marked *