In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
as unforeseen incompatibilities bring new "builds" to a halt. If 1,000 software updates have been submitted, it may take a while to narrow down the issues to their caused, or even to isolate the issues in themselves as some may have overlapping symptoms.
Continuous integration is a process of performing builds very regularly, at least nightly, if not more frequently, and doing basic sanity testing on the build, and a good dose of automated testing too, if you're so equipped to do so. When problems arise, they can be readily narrowed down to a few to a few dozen software updates. At this frequency of builds, problems generally arise in one's and two's, rather than by the bushel.
A second advantage is that the resulting build environment can be used by your development team. This can be from a simple confidence that they can use the latest built source code for their own testing, to generating shared compile/build environments for use in incremental builds or multiple subsystem testing. The more timely feedback on the cause of the problem is also helpful as the developer still has the changes clearly in his/her mind and has not fully moved on to something else.
If you want to build an Agile environment, continuous integration is a necessity. And the CM tools should support it. Settle for nothing less than fully automated builds without CM manager/Build manager intervention unless problems occur. If you can't do that, your processes are incomplete or your CM tools and procedures are too complex.
4. Data record Owner and Assignee
Ever hear the expression garbage-in garbage-out? Why does this happen? Developers take pride in their work. If they own a file and are responsible for all changes to it, they will treat it with a certain amount of respect and discipline. If anyone can change any piece of
code at any time, this care is lost. "So what" if Bob has taken care to keep his code concise and well factored. I need to make a quick change to fix a problem and I'm going to use a copy and paste method because it's the fastest (really?!). Bob, on the other hand, would have added a parameter to the existing routine(s) so that the same code
could be used for the purpose, without replicating functionality, bugs, and future code diversion.
Source code ownership is important. At the file level, at the branch level. But data ownership goes beyond source code. Every data record needs someone who is
responsible for it - for it's accuracy, for ensuring it runs through it's process, for assigning tasks related to the record and for tracking such assignments.
The best practice of data ownership is meant to help ensure data quality, and this helps with process quality. My recommendation - an "owner" who is responsible for the data and associated process/tasks involved, and an assignee who has been assigned to the next step in moving the data through it's process. For example, a development manager might have responsibility for a problem report, ensuring it gets successfully resolved. But
(s)he may assign it to a developer, then to a tester along the path to closing out the problem report. Every data record needs ownership in the CM world so that there is both accountability and clear direction.
3. Status Flow for all Records with Clear In Box Assignments
A close relative of data ownership, a clear state flow is required for each type of object. Your tools should clearly show you the state flow for each object, and a status should be tracked against every object. Each state transition should clearly identify the applicable
roles/permissions for the transition. It should be possible to specify additional rules, and triggers pertinent to the transition. When you put all of this together, your data along with the processes should be telling the team what needs