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 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 who did an 'update', or 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.
1 I think CI would be a nice safety net, too, to make sure I have all my code in a VCS, that all tests are routinely run, etc. Those are things that can easily slide if no one else has to build your code. – Michael Haren Jul 17 '09 at 13:39 Matt, thanks for this great answer. – Kishor Nanda Nov 24 '11 at 11:22.
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.
– Thomas Owens Sep 24 '08 at 23:35 1 You would be surprised how often a file is not checked in... – Benoit Sep 24 '08 at 23:41.
As other people have noted, CI does have advantages for a solo developer. But the question you have to ask yourself is; is it worth the overhead? If you're like me, it will probably take an hour or two to set up a CI system for a project, just because I'll have to allocate a server, set up all the networking, and install the software.
Remember that the CI system will only be saving you a few seconds at a time. For a solo developer, these times aren't likely to add up to more than the time it took to do the CI setup. However, if you've never set up a CI system before, I recommend doing it just for the sake of learning how to do it.It doesn't take so long that it isn't worth the learning experience.
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.
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.
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...
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.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.