Daily builds, is that realistic?

Question

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

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 2

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 3

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.