Is Continuous Integration important for a solo developer?

Question

I\'ve never used CI tools before, but from what I\'ve read, I\'m not sure it would provide any benefit to a solo developer that isn\'t writing code every day.

First

Answer 1

CI benefits a solo developer in the sense that you're aware if you forgot to check something in (because the build will be broken). The integration value of it is diminished when there are no other developers, though.

Answer 2

We use our CI system to do Release builds (as well as the usual automatic "on-commit" builds).

Being able to click a button that kicks off a Release build that steps through all the processes to release a setup is:

• fast (I can go straight on with other things, and it runs on a separate machine so it is not slowing me down);
• repetitive (it doesn't forget anything, including copying the setup to the release folder and notifying everyone who needs to know)
• dependable (no mistakes, unlike a human!).

In an Agile environment, where you expect to be delivering working software every 2-4 weeks, this is definitely worth having, even in a team of 1.

Answer 3

The benefit of CI lies in the ability to discover early when a check in has broken the build. You can also run your suite of automated tests against the build, as well as run any kind of tools to give you metrics and such.

Obviously, this is very valuable when you have a team of commiters, not all of whom are diligent to check for breaking changes. As a solo developer, it is not quite as valuable. Presumably, you run your unit tests, and even maybe integration tests. However, I have seen a number of occasions where the developer forgets to checkin a file out of a set.

The CI build can also be thought of as your "release" build. The environment should be stable, and unaffected by whatever development gizmo you just add to your machine. It should allow you to always reproduce a build. This can be valuable if you add a new dependency to your project, and forget to setup the release build environment to take that into account.

Answer 4

If you need to support multiple compilers then it's handy to have a CI build system to do all of that whilst you just develop in one IDE. My code builds with Vc6 through VS2008 in x86 and x64 builds on VS2005 & 8, so that's 7 builds per project per project configuration... Having a CI system means that I can develop in one IDE and let the CI system prove that all of the compilers that I support still build.

Likewise, if you are building libs that are used by multiple projects then CI will make sure they work with ALL of the projects rather than just the one that you're working with right now...

Answer 5

The truth is, that continuous integration makes most sense in teams. Single developers can also get some advantages, you must decide yourself if they are enough to counter the time you invest into setting a CI-system up.

• If you forgot to checkin some needed file, the repository contains a broken version, even if it works on your machine. CI would detect that case.
• If your CI-server runs on a different machine, it can indicate dependencies on your build-environment. Means, the build and all tests can work on your dev-box, but on another machine some dependencies aren't fulfilled and the build breaks.
• Daily builds can indicate, that your older software doesn't work with the newest upgrade of the OS/compiler/library...
• If your CI-system has an archive of build-artifacts you can easy get an distribution of an older version of your software.
• Some CI have a nice interface to show you metrics about your build, have links to automatic generated documentation and stuff like that.

Answer 6

The basic concept of CI is that you have a system that builds the code and runs automated tests everytime someone makes a commit to the version control system. These tests would include unit and functional tests, or even behavior driven tests.

The benefit is that you know - immediately - when someone has broken the build.
This means either:

A. They committed code that prevents compilation, which would screw any one up

B. They committed code that broke some tests, which either means they introduced a bug that needs to be fixed, or the tests need to be updated to reflect the change in the code.

If you are a solo developer, CI isn't quite as useful if you are in a good habit of running your tests before a commit, which is what you should be doing. That being said, you could develop a bad habit of letting the CI do your tests for you.

As a solo programmer, it mainly comes down to discipline. Using CI is a useful skill to have, but you want to avoid developing any bad habits that wouldn't translate to a team environment.