Daily builds, is that realistic?

Question

Hi,

In a 1-man shop or even (especially) larger shops, how in the world can you maintain a daily build?

If you change the API, or database table etc. you will have to potentially change so many layers in the application, or say the sql initialization script etc etc.

How can you expect the project to build for changes that take more than a day to complete?

Is it a development goal to ensure the build works accross every single change?

(btw, what I understand from a 'daily build' is pressing a button and having production ready code to ship...I am having a feeling I have the wrong option hehe)

Answer 1

In short...

Automate.

Dont check it in till it's done.

Yes.

Answer 2

The easiest way to have daily builds is to work in streams.

Have a development stream, a QA (or test) stream and finally a release stream.

Build your QA and release streams whenever they change. Build your development stream only when you need to.

Now you can make major changes to your development stream and then merge them (in source control) in a few easier operations and your automatic build process kicks off.

Answer 3

In a 1-man shop or even (especially) larger shops, how in the world can you maintain a daily build?

How in the world can you expect to keep things together without one? The aim is that every checkin to the repository can generate a clean build. If it can't, you're not doing things properly.

This is especially critical when large changes are being put into the source code repository.

How can you expect the project to build for changes that take more than a day to complete?

Easy, only build on the repository. Only check stuff into the repository that works.

Is it a development goal to ensure the build works accross every single change?

Yes, that's the aim. As with most aspirations, it's probably not going to be met, but having it as the goal gives good feedback on what's happening to the code base.

Answer 4

A daily build shouldn't require you to push a button. It should happen automatically, triggered either according to a particular time schedule or based on other events such as code check-ins.

It's a good idea to have code in the main branch in a permanently build-able state. Don't check code into that branch until it works. You can work on larger changes either in your own branch or by blocking out some of your application's new logic with flags.

You can deal with requirements like database schema, etc. by having your daily build script do all of the required set-up. Remember that you don't need to alter the production schema, since you won't be deploying your build every day—it should just be used for testing so that you can identify regressions as soon as possible.

Answer 5

Yes, the idea of daily builds is to test that your main branch of code is stable, passes tests, and is ready to ship at all times.

If you have a change that takes more than a single commit in your revision control system, then you should create a development branch, so you can commit freely without destabilizing the main branch.

Note that your database needs a separate test schema for each branch. I recommend a separate database instance for each test environment anyway, so this shouldn't be a problem.

Once you have finished this refactoring and updated tests, you should be able to manually validate that the code passes tests, and your daily build will not break.

Then you can merge the changes from your development branch to the main branch.

Answer 6

If it builds on your machine, it should build on the server. The thing is that you just check-in when you're done with your task, or use branches, so you don't break the build.

People don't do that necessarily to be able to put the product in a box at any day, sure, there may be routines that have to be done before release, but the idea is that any developer can get the latest code in the server and it will build in their machines. It is also used for automated unit testing; if the code does not compile, you can't run them.

Pretty much every large software company uses daily builds (actually, several builds a day), so yeah, it is doable and a common practice.

Answer 7

On my current gig, we do at least a daily build of our JEE app using CruiseControl, an Ivy repo, Ant & ClearCase. We're a large team and able to afford a build team (of 3) and build servers.

Yes the problems you name do happen such as mistaken DB changes, incorrect merges, broken compiles & tests. But overall we would not have it any other way.

Answer 8

I have used CruiseControl to implement Continues Integration which even creates new builds and deploys them on every SVN checkin, so the answer to that question is a definitive YES... ;)

Answer 9

Check also this question:

• Best Continuous Integration Setup for a solo developer

Answer 10

I have heard this complaint a lot, and even at my company.It's just a way of working. If you're not capable of having your stuff compilable and testable at all times, you're probably working on your problems in an erratic way, and are touching too much code at once. You're a juggler. Jugglers don't program.

On all my projects, we do HOURLY builds. We use Luntbuild to do that, and it will mail all project members as soon as the build fails, and will keep on mailing until the build works. Broken code does not get checked in, and when somebody breaks the build, he has to get cookies for the whole team (or other fitting "humiliation" :-) ).

Each week we try to do an installation of the software on our testservers, so that our test department can test the software.

You will see that this will result in better code, and a shippable project at almost any time during the project because:

• You are forced to break down your work in smaller, easier to grok and therefore easier to code pieces, which will result in less bugs.
• You are forced to update and check in often, which makes the project go faster because you benefit from reuse of your collegues earlier in the project.
• The code will be cleaner because you want to be able to write a unittest for it (otherwise the "coverage police" will get you)

I realize that this is not a real answer to the "how do you keep the builds working" question, I think there is not a really silver bullet answer for that. You just have to start doing it and see if it works for you. I think the larger part of the professional programmers agree that continuous integration, automated testing and daily builds are a goog thing.

My current project has 2 problems, one being that the buildserver does not mail due to a network problem, and the other being that there is too much panic. This means that failin hourly builds are noticed much later, and weekly installations are not possible because of unfinished functionality. You can immediately see reflections of this problem to the project, and the motivation of team members. It's just not going "smoothly".

I hope this helps. Keep them green! (the unittests, that is)

edit: The "pressing the button" you are refering to is the "single step build". It means that you have a script which does your build (or ant, or maven, or whatever), and you use that script to do the tests aswel. So when your automated buildprocess works, you know you have a shippable product. You just run the script and send the output to the customer. Our build script produce a directory structure which gets copied 1-on-1 to the CD we deliver the software with.