In our last 3 posts, we’ve reviewed
- the benefits of issue based development,
- the new product features in AccuRev that have been released in v6.0,6.1 and soon to be v6.2 that further support for issue based development
- general issue based development best practices.
In this final post in the series, we will not pull it all together by outlining stream structure and promotion guidelines.
Let’s start off with a very simple path for development, which lends itself to agile methodologies. The hierarchy represents working through a mainline release structure, with sprint/user-story “topic” streams. Cut releases each month for sprints/iterations & continue working against mainline for subsequent releases. This same model can be applied for collaboration streams, feature streams, componentized streams, or any logical subset of code that can help eliminate a large, shared, integration “build-up” of active changes.
Issue Based promotion vs Transactional Promotion
This is the point we would want to dictate where change packages are going to be “in play” during the development life-cycle process – meaning, promote by the change package task(s) through user-story streams into sprint streams, & use transactional promotes from that point forward. Change packages should encapsulate “tasks” assigned to developers & each specific development task will be assigned off of an associated user-story stream that pertains to the task(s). The objective is to allow isolation & flexibility at a user-story stream level (development) while alleviating dependencies which would occur immediately without smaller encapsulation of grouped tasks. In other words, you are more likely to hit file dependency issues against a large, integration stream without the division of user-story/topic streams.
In the case above, user-story streams serve many important purposes:
- Determine task(s) that are still in-flight or may not be able to meet the sprint deadline. This is easily queried by the active changes icon on the user-story stream. From that point decisions/actions are easily made to apply more pressure to developers, assign more development resources, or slip to the next sprint. Refactoring to the next sprint is a simple drag/drop of user-story stream to the next iteration. Work in progress (tasks) move automatically along to the next sprint & tractability is perfectly attainable.
- Isolation of builds & tests at a segmented/componentized level. Almost guarantees a stable, testable, full integration environment.
- Quick delivery/test of working component at a user-story level.
- Allows isolation of pushes upstream (promotes), yet allows for continuous integration pulls downstream (inheritance). Integration through inheritance will significantly reduce merge & dependency conflicts.
Do not think that this process can only work if the project is only following Agile development practices, the same logic applies for any logical breakdown of project’s – components, features, sub-projects, collaboration, etc. The key aspect is to isolate away from the super-sized, integration bucket as much as possible. Integrate smaller & often.
That being said, how should the change packages be propagated into the development pipeline (official builds, official testing, & production delivery)?
As active changes accumulate within the full, integration stream, it logically makes sense to propagate upstream via transactions at this point. This guarantees that what was built & smoke tested will be in the same baseline upstream. This method completely eliminates change package dependencies during upstream promotes and allows for quicker, reliable propagation. Change packages will follow the transactional promote giving complete visibility & tractability at the issue level.
Promote out of INT & QA streams up to the last transaction that was built/tested. A known, validated baseline will provide the most streamlined approach and efficient results.
The following basic best practices should be applied when working with change packages.
Follow Promotion Rules to Avoid Dependencies
Following these promotion guidelines will help you avoid dependencies.
Promote by Default Group or Transaction as a Common Case
Change Package dependencies & “patching changes” only becomes an issue when a sub-set of packages in a stream’s default group are promoted forward while others are left behind. This type of selective promotion and cherry picking is a powerful capability that Change Packages supports, but should not be the core practice that an IBD process is based upon. Basing and IBD process on a common case where promotion from stream to stream is done by selecting all change packages within the default group (the entire contents of a default group is promoted as a single transaction) or transaction (all active transactions <= a know validated baseline transaction are promoted) will provide the most streamlined and efficient results.
Stream structure becomes an important consideration in achieving this. The stream hierarchy must be designed to encapsulate deliverable units along the process. For example, as simple stream hierarchy with the following levels in the hierarchy would look like Release<-Project<-Feature<-Topic. A stream structure needs to balance support of the delivery decision making and software integration.
If Change Packages are promoted independently by issue preserving FIFO order will minimize dependencies. For example, if CPK A, B, and C are promoted to a “DEV” stream in order, and all have revisions of foo.java affiliated with them, then promoting them to a parent “QA” stream in one of the following sequences will avoid dependencies:
Cross Promote to Workspace
This drastically reduces the amount of clashes (deep overlaps) between files due to inheritance – take care of the issues in a workspace and follow the defined process upstream. Promote safe and strict practices.
Promote Large Batch CPKs to Shared Configurations Quickly
Large, sweeping changes to the core baseline can be assigned to a Change Package but must be moved quickly through the process. Meaning, get the Change Package out of the way because any subsequent changes will create Change Package dependencies. Ex – adding copyright info to the whole code-base.
I hope this series was helpful. If you’d like to diver deeper, please contact us, and we can schedule time with one of our solutions engineers.