The document discusses best practices for building software including: - Creating build scripts that are decoupled from IDEs and can be executed by a CI system on every code change. - Ensuring builds can be executed with a single command and do not require an IDE. - Centralizing software assets to reduce broken dependencies when moving to different machines. - Creating a consistent directory structure to easily build the software. - Failing builds fast by executing activities most likely to fail first. - Using a dedicated integration machine and CI server to automatically run builds.

1. Chapter 4
Building Software at Every Change
Neider Carrillo Vera
Yenifer Barco Castrillón

3. Automate builds
Create build scripts that
are decoupled from IDEs.
Later these build scripts
will be executed by a CI
system so that software in
built at very repository
change.

4. Perform single command builds
Assuming certain tools have
been downloaded, you
should be able to type one
command to execute a build
from your build script to get
the latest code and run an
entire build.

5. Separate build scripts from IDE
You should be able to run your automated build without needing an IDE.

6. Centralize software assets
To decrease the number of broken dependencies, centralize all
software assets. This lessens the chance of broken builds when
moving to a different machine.

7. Create a consistent directory structure
Create a consistent, logical directory structure, which makes it easy to
build the software.

8. Fail builds fast
The faster the feedback occurs, the faster the problem can be fixed.
Execute build activities in the order of what is most likely to fail first.

9. Build for any environment
Run the same automated build on your workstation, on the integration
build machine, and for any other platform environment as necessary.

10. Use a dedicated integration build
machine
Use one machine dedicated to running your builds. Ensure that the
integration location is free of old build artifacts.

11. Use a CI server
In addition to or as an alternative to running manual integration builds,
use a CI server, such as Cruise Control, to automatically poll for version
control changes and run an integration build on a separate machine.

12. Run manual integration builds
Run a sequential integration build manually using an automated build as
an approach to reduce integration build errors. Some use this approach
as an alternative to a CI server.

13. Run fast build
Try to get your integration builds down to ten minutes by increasing
computing resources, offloading slower tests, offloading or reducing
inspections, and running staged builds.

14. Stage builds
Run lightweight “commit”
builds that perform compile,
unit test execution, and
deployment followed by
heavyweight “secondary”
builds that include
component, system, and
other slower-running tests
and inspections.