1

I have a general question regarding best practices. I have a small team working on a medium-scale software project, which involves integrating code from different environments, etc. The project is a standalone piece of desktop software.

Based on lessons learned from a similar prior project that went badly, I am trying to implement some better software engineering practices.

I'd like to start by automating daily builds. We use SVN for source control, and all the developers are working in the trunk, including me. My question is rather simple:

Where locally do we do the daily builds? Should I make another folder on my local machine that is the "daily build" folder? Should I set up a virtual machine? Should I suck it up and do it in my development folder?

I understand the revision control paradigms pretty well. I'm mostly looking for how folks implement it in practice.

  • 1
    As far as I've seen, teams would have a dedicated "server" that hosts both the version control and continuous integration (and possibly a tracking system as well). Whether it's a dedicated physical machine, cloud hosting or just a set of programs running 24/7 on a dev machine is up to you and your budget really. – Ordous Jul 22 '14 at 17:38
  • @Ordous So, given that we don't (yet) have that capability, would you say that maintaining a separate folder on a dev machine, checking out from a release branch, would be the best near-term solution? I'm slowly trying to drive the company towards some of those solutions, but it won't happen quickly. – Emily Jul 22 '14 at 17:41
  • 2
    If your team is on a single network, I would simply start up a local Jenkins (or other CI server) on my machine. It would do the checking out, building etc on it's own nice configurable schedule and also do clean-up. The only downside really is that it will require disk space and will slow the machine down while building. But when those become real problems - you can probably request a dedicated machine. – Ordous Jul 22 '14 at 17:46
  • 2
    Steve already posted something along those lines already, I don't care enough about rep to post a almost complete duplicate on the grounds of comments being a couple of minutes earlier. – Ordous Jul 22 '14 at 17:51
  • Very well. Much appreciated :) – Emily Jul 22 '14 at 17:51
4

A build machine is the way to go, even for small projects/teams.

  1. Get any random spare machine (ie. an old dev box).
  2. Install some continuous integration software on it like jenkins or teamcity.
  3. Done

It's been a while since I had to set one up or maintain a build machine, but unless it's gotten worse since a year or 2 ago, you can have continuous builds on each checkin, and a nightly build that gets dumped to a network share setup in maybe an hour with either of these products.

  • Another nicely working continuous integration and build server is the cruisecontrol.sourceforge.net/index.html. It took some days to set it up. But once up and running it worked flawlesly without any administration – xmojmr Jul 22 '14 at 17:52
  • 1
    @xmojmr: if I recall, CruiseControl was one of the original CI packages that helped get CI as a mainstream practice... but the project is abandoned (latest release is 4 years ago). It's OSS though, so that's better than completely dead... but still not one I'd recommend. – Steven Evers Jul 22 '14 at 17:56
  • 1
    Damn it. We used the CruiseControl back in 2009 (it was very cool tool at that time). Since then I'm working on different projects (different company) and we use Microsoft's Team Foundation Server, once configured it also works flawlessly and integrates very nicely with Visual Studio - but it is not free and not available outside the Windows platform - and the configuration takes some more more days to get right – xmojmr Jul 22 '14 at 18:11
0

Presuming your app can be built from the command line given a clean checkout and pre-requisites preinstalled you can mechanically do it with something as simple as a cron job or scheduled task. But what you really want here is known as a continuous integration server.

These servers handle a couple of things:

  • they make it easy to orchestrate the "go build this every day at midnight" or "go build this every time someone checks in" by providing scheduling facilities.
  • they extend that basic build by providing feedback mechanisms -- such as emailing the whole team when Bob breaks the build.
  • they can provide long-term reporting on build performance and success over time.
  • can provide the plumbing to automate packaging and publishing of an application where appropriate.

Or, they are effectively the brains of a modern development and deployment process.

There are two products that are good to start with in this field -- Jenkins which is free and open source and TeamCity which is free for your scale but not open source. Both will get you where you need to go, which one to pick is really a tactical decision based on what you are building stuff in and how much effort you might want to put into configuring the thing -- not that a basic setup with either product is horribly involved if you've ever stood up a and configured a web application. They are anatomically similar so the rest of this answer will apply to both.

These products both have a central server which is what you interact with as well as a concept of build agents or workers where the builds take place. This seems a bit odd until you realize that you could be building a cross-platform product that needs a native windows, osx and linux build.

In terms of where to install it that is really a tactical decision -- they both are very flexible java products that will run on just about anything. It really boils down to avaliability of hardware / software / licensing and security -- some folks really want to keep everything on the LAN. As for the build agent that is also a tactical decision. There is no reason the agent can't be on the same box as your CI server but you could certainly drop it somewhere different if need be. Having it on the same LAN helps unless you want to do some network configuration as they do need to communicate and typically that requires some firewall hole punching.

I probably would not install this on a machine someone was actively using just to guard against someone turning the machine off. Or hosing the machine and breaking your CI process. But mechanically an old desktop will do -- we just retired a ~2005 era HP desktop that was the main build server for every one of our dozen plus QA sites that got built pretty frequently. It's main issue was that we could only put 2gb of RAM in the box so we could not cache a lot of things in ram and it would page out to a slow disk made by the lowest vendor operating well beyond it's expected service life.

tldr: get Jenkins or TeamCity, install on a spare desktop, conquor the world.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.