You might need Continuous Integration if…
It looks as if this may have been posted a while ago, but very useful nonetheless. It’s called 34 signs that continuous integration isn’t working. I understand why it was entitled this, but I think the title is a bit misleading. I think a better title may be: “34 symptoms that you might need (effective) Continuous Integration”. The article is almost like a list of smells that indicate you may need a better way to integrate your changes. I’ve identified some of the practices we describe in the Continuous Integration book to combat these “smells”.
Here are some great ones:
- Everyone has a different set of projects checked out on their PC (Perform Single Command Builds, Centralize Software Assets)
- You don’t have a master build script that builds everything on any (workstation) (Automate Builds, Centralize Software Assets)
- You sometimes check in without catching up with other people’s changes (Run Private Builds)
- You hate/fear checking code in (Commit Code Frequently)
- It’s difficult to take a (’cut’) of the code that’s consistent enough to make a release… (Perform Single Command Builds, Centralize Software Assets)
- It takes forever to make a release
- Things that were working fine suddenly stop working (Perform Single Command Builds)
- If you want to know what code is running live, you checksum or diff it against known versions (Build for Any Environment)
- The code works in development and pre-production, but not in production or test (Build for Any Environment)
- You are only allowed to release in the middle of the night/weekend/both (Release Working Software Any Time, Any Place)
- Releasing a one-line fix for a show-stopping production bug is “too risky” (Label Each Build, Label a Repository’s Assets)
- You often check in only some of the changed files in your workspace