When you edit code, an automatic build system can notice the change and rebuild the project. Your next step is to publish that information so that every member of the team knows what changed. A change notification system pushes this information out to your entire shop, not just your immediate co-workers. The preferred way is to have your changes automatically emailed to each team member. Most automatic build systems will send changes for you (and they’ll usually publish your changes to a web page and RSS feeds as well). Change notifications should go out to your team each time code is checked into the source code management system. Notifications should include:
- Reviewer’s name.
- Purpose of the code change or addition (for instance, which bug you’ve fixed or which feature you’ve added).
- Difference between the new code and old code (Any major source code management system will generate this report for you.) If you’ve completely rewritten a block of code so large that it would make a diff meaningless, just include the new code. The same applies to new files.
How to Get Started:
- A program that watches your SCM generates notices and sends emails.
- Make sure your team knows about the notifications before they start arriving.
You're Doing Right If...
- Notifications must be regular and trustworthy.
- Don’t send out five-megabyte diffs!
To make this work you would need to customize your SCM a bit. You'll need something to trigger the CI server when a commit occurs. You'll also need to put something in that verifies that the requisite data is in the check comment. One question I have is around the volume of information that could be generated. Changes to one branch of the code might be okay but what if there are multiple branches?
No comments:
Post a Comment