Releases

A software release is the sum of the stages of development and maturity for a piece of computer software. Releases continuously increase the feature set of your application without prolonging the wait

Why we work with Releases

1. The whole agile process is coordinated around Release, means we build, test and reviewied in every Release.

2. The process involves several activities that include requirements analysis, code development, creating the build, deployment, and software testing.

3. A release is a collection of tasks and requirements to be implemented in a specified time.

4. Releases are the key for every successful project, the complexity of requirements and eventual complications can be avoided.

Types

We differentiate between 3 types of releases to further enhance the flexibility of implementing features while still maintaining the stability and continuity of the production application.

Feature Release

Contains stories and tasks which enhance the application with new features and functionalities. All of those require (as a rule of thumb) more then 4 hours to be implemented and are connected to a wider set of functionality. Those releases are generally longer in duration > 2 weeks as the complexity of tasks require the time to be implemented and tested. Tasks and delivery is planned in advance together with the client to control feature rollout timelines.

Refinements

Refinements discovered during acceptance phase will enhance the feature release with additional tasks that are collected separately in a release marked as "Refinements".

Support Release

The agile counter part to our feature releases, short duration < 5 working days, issues and corrections which urgently need to be delivered to the client. This improves the stability and continuity of the current production application.

Sprint

A time-boxed container for collecting and implementing issues that don't require immediate production deployment. Unlike Feature or Support releases, Sprint Releases focus on continuous improvement, technical excellence, and maintaining system health. They typically include tasks like technical debt reduction, performance optimizations, internal tooling improvements, and minor enhancements that can be deployed at a convenient time

HotFix Release

Used in case of a critical issue on any production application, containing one task solving the problem.

Phases

To monitor and track the current progress and state of a releases we defined following 7 states.

• PLANNING - Collect requirements and define the timeline

• DEVELOPMENT - Currently in development

• VERIFICATION - Internal implementation testing

• TESTING - Currently deployed for acceptance testing from client

• AUTHORIZED - Client approvoed the release (via QA), the release is now available for deployment

• ARCHIVED - Archvied, not anymore available for deployment (deprecated)

Software Release Cycle

The software release process outlines the structured approach to developing and deploying software changes through clearly defined phases. Each release type (Feature, Support, HotFix, and Sprint) follows these phases to ensure quality, compliance, and efficient delivery.

• Planning Phase: Collect requirements and define available resources. Clients add tasks based on their estimation and resource availability. This phase establishes the foundation for the release scope and required effort.

• Development Phase: Active development begins, marking the release's start date. Developers implement changes according to specifications while logging actual hours for effort tracking and due date calculations.

• Verification Phase: Internal implementation testing occurs, ensuring code quality and functionality. Upon successful verification, the release becomes eligible for staging environment deployment.

• Testing Phase: The release is deployed to a staging environment where clients perform acceptance testing. This phase ensures the changes meet business requirements and quality expectations.

• Authorized Phase: Following successful client testing and approval during QA, the release becomes available for production deployment. For Support releases, version numbers are required at this stage.

• Archived Phase: The release is marked as deprecated and no longer available for deployment, completing its lifecycle.

This process supports different release types while maintaining compliance with standards like ISO 27001, NIST, and SOC 2. It emphasizes clear phase transitions, documented approvals, and quality gates while allowing for agile delivery through flexible release types. The automated due date calculations based on estimations and logged hours enable realistic planning while maintaining agility."

Numbering

Every release (so called version) has predefinition numbering system so everyone can track progress.

Release plan example