Let's write some code!
So, all you need for a CI process is three things: a build, an SCM, and CI server. You have all three and they're set up and ready to go. Of course, for CI to be useful, you need to write some code and set it in motion. In this section, you'll see how a CI process works from start to finish.
Before diving into a start-to-finish CI scenario, it's probably helpful to define what I like to call the cadence of development when working with CI. Having a CI server run builds doesn't preclude you from running local builds yourself. In fact, with a proper CI process in place, which notifies you of a failure in the SCM, it pays to ensure everything is working smoothly before you check in any new or modified code. Doing so will spare everyone the needless noise that could otherwise occur.
Accordingly, the cadence of development in a CI environment looks something like this:
- Do an update of your local sandbox.
- Modify some code.
- Write some tests.
- Run a local build to ensure you haven't broken anything.
- Execute an update to ensure you have the latest code from the SCM, then run another build to see that things are still good.
- Check in your changes.
Note that Step 5 is crucial when you're part of a team where people are working simultaneously on the code base, especially if you've been at it for a long time.
Hopefully most developers will find the cadence of CI quite natural. It's a good working rhythm in or out of a CI environment!
So now it's time to start doing some real work. For example, when Hudson ran the first build of the example project, it discovered two JUnit tests and ran them; accordingly, it reported that two passed and that two were new, as shown in Figure 11:
Figure 11. These tests ran swimmingly well
You're right to be pleased that these tests passed, but let's say you have a hunch that they don't offer enough coverage by themselves. (Of course, you could obtain a coverage report to avoid hunches, but for now we'll stick with intuition.) To ensure the code is solid, you'll write two additional tests, run them locally to verify they work, do a quick update, run the build again, and then check them in. After that, you'll write another two tests and re-execute the same steps.
After you check in your two new tests, you can go to the project homepage to check their status. Within a few moments, in the Build History box, you'll notice a pending build. Yep, Hudson has detected a change in the SCM repository!
Figure 12. Hudson responds to a change in Subversion
Hudson's Build History box shows a pending build in Figure 12. After the build completes (hopefully in a passing state), you can click the build's date to receive more detailed information, as shown in Figure 13:
Figure 13. Details after running two new tests
Figure 13 shows the changes that triggered this build. You can click the detail link next to each change to see more about the changes, such as who made the changes and their commit statement, as well as the particular detail shown in Figure 14:
Figure 14. Two revisions were found in this build
If you go back to the build status page and click the Test Result link, you can also see that two new tests were run and that all four tests run so far have passed, as shown in Figure 15:
Figure 15. Test report
When you configured this project, I had you point Hudson to JUnit's result files but didn't tell you why. I wanted to demonstrate a great out-of-the-box feature that Hudson supports. For each build, it will parse the corresponding JUnit result XML files and build a trend graph. In fact, if you go back to the project's homepage, you'll see a trend graph showing that for two builds so far, the test count has doubled.
Figure 16. Not a bad trend —100% growth
The trend graph in Figure 16 shows that the number of tests has doubled between Builds 6 and 8 (which, in this case, are sequential builds).
If you write two more tests, the trend graph in Figure 16 will continue to show a very good trajectory. That is, as each build is run, the amount of tests run is increasing. You can also see that those tests are consistently passing because the graph is blue, rather than red, shown in Figure 17:
Figure 17. Keep that test trend up!
Tests aren't the only aspect that Hudson will trend out of the box. Hudson also trends build execution times, which can be handy in ascertaining build performance. For example, as builds begin to take longer to execute, you may have to start thinking of different ways of running tests, for example, categorizing them for quicker builds.
Figure 18. Hey, those tests take time to run!
The data shown in Figure 18 clearly indicates that tests add to the overall time of a build — compiling those tests takes time, but you'll find that it is a much smaller amount of time compared to running them.
Speaking of trending, if you go back to Hudson's homepage, you can see a list of project's that Hudson is currently managing. Various data items are found in its project table. What is particularly interesting is the second icon in the W column: an intuitive visual clue corresponding to the overall health of a monitored project. In your case, as shown in Figure 19, the icon is a bright sun indicating that tests are passing, and so are all builds:
Figure 19. Sunny days lie ahead
Just like in real life, not all days are bright and sunny; when things are going bad, for example, projects aren't building or tests are failing, Hudson reports a much different picture, as shown in Figure 20:
Figure 20. Watch out for storm clouds
If you look closely, you'll see the pop-up indicating that one particular project has a build stability of 79% and a test stability of 97%, which amounts to a partly cloudy day. The top project is really having a bad day though — it's practically a hurricane!