Multi-hump software deployment process is a concept of a release process where multiple release candidates are progressed through development and testing phase until given build is deemed good enough to production. The key concept of multi-hump process is to manage two distinct phases: development phase and stabilisation phase in each development iteration.
In two hump-development each iteration represents a stage of building a specific software version, essentially representing a release candidate for production. Initial iterations represent prototyping new features and changes along with developing business requirements. Subsequent humps increase amount of specified and implemented features ready for testing. Each iteration however focuses also on improving features already passed to review by business stakeholders and quality assurance, as well as building detailed test cases and addressing regression issues spotted.
- Red area - amount of work spent on new features and change requests
- Blue area - amount of work spent on business requirements and software specification
- Green area - amount of work spent on developing software test cases
- Yellow area - amount of work spent on discovering and fixing errors and issues
Typically multi-hump process is best suited to continous releasing of minor versions of an application, as defined by a pattern of (major).(minor).(patch).(build) versioning pattern with each 'hump' representing a different minor/patch version within a given (major) target. Patches are typically aligned with timing of sprints, if multi-hump process fits into agile approach to the development process, allowing teams to demonstrate a working release candidate at the end of each sprint.
- Author
Maciej Zagozda
Company founder, and director of engineering.
- Comments
- Leave a Comment