Last week I wrote how important it is you can set up your build environment by running just one command.

Well, perhaps it is a worthy target to aim for, even if you miss it slightly. I showed you our build environment set up:

$ wget -O- http://server/1cmdenv.sh | sh
$ cd universe
$ make client-server-5.5x


Strictly speaking, that’s 3 commands (wget, cd, make). I’ll argue that cd is not really a “command”, as such, and since we have so many source trees you need 2 commands: 1 to check out the “tree-of-trees” or “universe” as we call it, and 1 to check out the source tree you want to build. I would say that is as close to one command build environment setup as we can get.

The other alternative would be to create separate setup commands for each source tree. Then where do you store these commands? Probably in the version control. But then you need another command to check them out. So, 2 commands is reasonably close to the ultimate goal.

Now to the subject of this post: The one command build.

We have chosen the one command to be: make. Running just “make” with no parameters performs a full build. With full build I mean it produces the installation package that is shipped on cdroms and uploaded to web sites.

Whatever the command is, it is important it does everything with no manual tweaking.

If there are manual steps in your build procedure, someone, somewhere, sometime when you least expect it, will get them wrong. Script it. All the way.

Even when your build is just one command, someone will think he is in a hurry and he doesn’t have time to run the one command. He will try to cut corners. He will think: “I already have module 1 built on my workstation. I’ll use that and build modules 2 and 3 by hand and execute the packaging command from the temp directory. I’ll save 10 minutes.” Beware! That is the way dragons lie.

What’s wrong with some shortcuts? Nothing if you can be absolutely sure you know what you are doing. Can you? Do you trust yourself? You do remember what causes most accidents in nuclear power plants? Human error.

4 months ago one man at the waterworks of Nokia, Finland (the city, not the phone maker) accidentally left one valve open and as a result contaminated the drinking water of tens of thousands of people. It took months to clean up the water pipes.

Long, long time ago I attended a lecture on fault tolerant systems. The lecturer said: “If you only remember one thing about this lecture, let it be this: The easiest way to build a fault tolerant system is to place the system in a very strong cabinet, lock the door and lose the key.”

In other words, eliminate the human factor.

When we run “make” in our source tree, it will do at least these things:

• generate dependencies
• export header files and string tables from a MIB file (contains all the settings and alerts of a software product in the F-Secure Policy Manager system)
• run a Perl script to generate code from the headers exported in previous step
• run another Perl script to verify string tables above match the localized string tables
• compile and install the unit test framework
• compile and run unit tests
• run a few static analyzers
• compile everything that is needed
• create RPM and DEB packages from the compiled code
• create a self-extracting installer from the RPM packages and an APT repository from the DEB packages
• export system tests from the source tree to be executed on the build by an automatic test system
• copy all the stuff that was generated to a separate file server

I’m sure I forgot a few steps in the above list. There’s too many to remember. The beauty of it is: I don’t have to. The one build command does it all for me.

When the build is just one command, it is easy to automate it. When the build just happens automatically, it further removes any possibility to screw it up. Create a cron job to make the build every night.

When you have a cron job making the build every night, why not make it every hour? Or every 15 minutes? When you have that, why would you bother making a build by hand ever again if a cron job is going to do it anyway in a few minutes. And it will do it better than you. Always the same way.

That sounds like Continuous Integration. Maybe I’ll write about that next week.

Just to make sure the message goes out: as mentioned by our colleagues in the lab, this week we released an important security advisory “FSC-2008-2″, about potential vulnerabilities affecting components common for many of our products, including Linux products. If you’re running one of our Linux products, chances are that you are affected and you should upgrade to the latest build immediately. Read the advisory for more information, or get more details from CERT-FI.

To get e-mail notifications about maintenance releases, subscribe to our maintenance release notification mailing list.

We are going to write a series of posts on good practices concerning software development, configuration management, building, testing and methodologies. The stuff in these posts will not be vague, abstract ideas but real lessons learned by veterans in the trenches of the battlefield.

This is the first post in the series, so let’s start from the beginning.

Everyone of us has been in this situation: You are the new guy in the team. You have just set up your computer. Email and web browser works. You are eager and ready to start coding!

What is the first thing you must do to start coding? You must install some tools and libraries. You must find out where to get the source code. Which version control tool do they use here? Where is the repository? Who do I talk to get access?

Do you remember how long it took before you were able to build the source code you were supposed to be working on? And build it in such a way that it really resulted in something that installs and works?

It probably took you anywhere from a few hours to a few days (and I have read about horror stories where it took weeks.)

Why?

Because the old hands in the team already have their own build environments set up and have had them for years. Their workstation has all the tools, all the libraries and all the little undocumented tweaks that are needed to make the perfect build. The build environment has not been set up, it has more like grown or evolved. Documentation, if any, is probably outdated.

The only way to avoid this mess is to make it possible to set up a complete build environment by running one (1) command in a clean workstation.

Why one command? If there are two commands, you might not remember them both or you might run them in the wrong order. If there are more commands, you definitely will not remember all of them.

And why would you bother with anything more than 1 command? If you currently need to run 2 commands, make a script that runs them. Now you have only one command. You have just automated the whole set up process and reduced the number of things you need to remember about it by 50%!

What this command does is entirely up to you. It can install software from network drives, copy files, check out source code, whatever is needed to turn a freshly installed Windows or Linux or Mac into something you could replace your build server with.

If you have such a command, it is probably a script. You do not need documentation, just read the script. If there is some obscure stuff in the script, write a comment into the script.

Test the script. Get your boss to buy you a new, shiny, fast workstation and use the script to set up your build environment on it. (If your boss refuses, set up a fresh virtual machine or something.)

And best of all, if one day you see smoke coming out of your build server, you know how to make a new server in no time at all.

We in the Linux team have a script that uses apt-get to install bazaar, configures it, then checks out an Arch project that has a Makefile. This Makefile is used to check out the various source trees we work with. The Makefile also knows which tools you need for which source tree and will install the tools before checking out the source.

This is how it would look if you wanted to make a build in a clean computer:

# One command build environment setup
$ wget -O- http://server/1cmdenv.sh | sh
$ cd universe
# Check out one source tree and install the tools it needs
$ make client-server-5.5x
$ cd client-server-5.5x
$ make testbuild
# Now install and test the build in ./release directory


Of course, it may not be a good idea to depend on tools and libraries that are part of your OS. When you upgrade the OS, you sometimes get new versions of them that are not compatible with the way you use them. But that is a topic for another post.

We have just released a new version of F-Secure Linux Client & Server Security. This 5.54 is mainly a bug fix release, including a new Automatic Update Agent and making the Web User Interface work properly with Microsoft Internet Explorer 7. Please check the release notes for more information on what has changed. As always, we recommend upgrading to the latest version even if any of the fixed issues do not seem to affect your environment. Please feel free to ask if you have any questions regarding this upgrade, and do drop us a note telling how the upgrade went :) The email address is at the bottom of this page.

The product packages and release notes are available from our Webclub:
F-Secure Linux Client Security 5.54
F-Secure Linux Server Security 5.54