No one wants to break the build. However, every time you check in code, you risk breaking the build. This leads some developers to avoid checking in for days (or weeks!) until they have a dangerously-big component. That has its own problems. Integration is pay-me-now-or-pay-me-later. I'm a big fan of paying upfront with small, continuous check-ins. Here are some tips to do check-ins without breaking the build:
- Try to do multiple smaller commits as opposed to one giant commit.
- Where reasonable, try to keep a component split into multiple smaller files instead of one giant file, especially if these files are updated by many developers. This reduces contention, and hence likeliness of breaking the build.
- Check in a file that won't hurt anything, like a class file that's not added to the project yet.
- Make sure you understand how code-generation integrates into your build. It's easy to have the code "work on your machine", only to have a code-generated script on the build server overwrite your changes and break the build. Make sure all your local code is in sync with what will be actively code-generated.
- Make sure you always check in all the needed files, especially files that get "registered" with a master file list. For example, C# files get registered with a csproj project file.
- Use a source control that allows merging (SVN, not VSS)
- Split your code into isolated components - i.e. reduce dependencies in your code.
- If you're working on a unit test, and you "need" (?!) to check in a partially-completed test that currently breaks, then consider applying the "Ignore" attribute so the test doesn't run yet.
- If you really need to check it in, perhaps comment out the breaking section.
- If you're checking in to send code to another dev, consider not checking in, and sending them a patch instead
- If you're checking in to the global trunk just to "back up" your work, consider checking into your own private branch.
No comments:
Post a Comment