Nightly / Daily build

A nightly build is an automatic build that takes place when nobody is around, usually at night or during lunch hour. It is automated by a script that ensures no bugs were introduced and all dependencies are available.

Table of contents.

1. Introduction.
2. When we might need nightly builds.
3. How to perform a nightly build.
4. Advantages of nightly builds.
5. Summary.
6. References.

Introduction.

A nightly build is an automatic build that takes place when nobody is around, usually at night. This build comprises everything that was checked into the source control. It is done during off-hours so that no changes are made during the build.
During this build, the software is checked to ensure that no bugs were introduced and that all required dependencies are available.

When we might need nightly builds.

The following are some of the scenarios where we would want an automatic nightly build.

• During unit testing, here we want to be alerted of errors that occur during testing.
• Where we have stakeholders who review and comment on the new checked-in features.
• In cases where we have SOA(Service Oriented Architecture) shared services and want to execute tests over older versions.
• In cases where not all developer instances have full data sets or production data. Here new tests are automated in the nightly build to test and report changes made to the code against a complete dataset.
• Nightly builds are also useful for lazy branching, whereby we have multiple features being developed for a single release and may need to roll back to a stable version since implementing a feature drags the timeline.

How to perform a nightly build.

The first step is to find a build server, it should be the fastest computer.
Next, we write a script that checks the current source code and builds every version that is shipped.
We should also place a build in its directory that is named using a timestamp.
We execute this script at a specified time every day, it could be nighttime when no one is working or during lunch.

Key things to note:

• Everything needed to generate a final build must be included in the script, this includes installers or setup programs. This way we make sure that nothing about the build process is 'documented' in one's head.
• As a rule we should only ship code that is produced by a full, clean nightly build that started from a complete checkout. This means no buggy code will be shipped no matter how tiny the bug.
• We should also set compilers at the maximum warning level, in these cases, they stop once an issue is encountered. Even the smallest one.
• The build script should also grep errors and send them via email to the whole development team. It should also produce status reports on a beautifully designed HTML page visible to all so testers or developers can determine what builds were successful.
• Daily builds don't have to be done at night, sometimes, a team could be operating in different time zones. In such cases, it is better to perform builds during lunchtime so everyone checks in their code before lunch, and after lunch, the bugs that presented themselves can be fixed. Also, when teams are in different time zones it is wise to have a schedule so that one team or party does not hose other people in another time zone.
• If any particular build is broken, we should drop everything to fix it before shipping it.

Advantages of nightly builds.

1. Outsiders such as marketing, and beta testers who use the older build pick up a new stable build and use it.
2. Easier reporting of bugs, the tester only needs to know the right build where he/she found the bug.
3. Developers are confident that changes made won't break the previous versions.
4. When a bug is sorted out, testers receive a new build to retest and check if the bug was fixed.
5. Most times we have a large archive of builds and when a bug is discovered we have no clue where it came from. To find it we run a binary search on the historical archive to pinpoint where the bug was first spotted.
6. Developers who check-in changes right before the scheduled daily build cannot trick everybody else by checking in a build that breaks the build.
7. Saves time since developers don't need to run the build manually.
8. Since nightly builds run at night or during a lunch break, it does not interfere with regular work.
9. Easier problem solving as bugs and status reports are reported.
10. Bugs are fixed before they contaminate new branches.

Apart from the above nightly builds also assist teams in the following:

• To check the status of the build machine and script. If either fails, then we won't have a final build.
• Check if necessary certificates have expired.
• Check if a party forgot to check in a crucial file or change.
• To avoid hosing whereby a party checks in something that breaks the build.

A side-effect of nightly builds is that it forces developers to maintain the build script that automates the nightly build.

Summary.

Nightly builds take place when nobody is around, this can be during the night or lunchtime, or any scheduled time when the team is not actively working. It is automated and therefore all that is needed is a script that runs at fixed times during the day. The script generates status reports which we present on a colorful HTML page for a stakeholder such as a client/a tester to see.

The developers can locate bugs and fix them for retesting by the testers who verify if the bug was indeed fixed.

Commonly used tools for nightly build infrastructure are Jenkins and Teamcity

With this article at OpenGenus, you must have a strong idea of Nightly / Daily build.