Skip to content

Release Management

Jump to bottom
Vesa Härkönen edited this page Jan 9, 2015 · 23 revisions

EduCloud

Effective release management begins by controlling the process through formalized steps to plan, schedule, control and approve releases. Several of the tasks involved in controlling the process benefit substantially from automation.

Tools:

Establishing a release cycle is vital

  • It creates an opportunity to meaningfully discuss nonfunctional testing that the software may need.
  • It announces a timetable for when stakeholders can expect to get some functionality. If they know that functionality will be regularly released, they can get on with agreeing what that functionality will be.
  • It creates a routine with which all teams can align (including marketing and engineering).
  • It gives customers confidence that they can order something and it will be delivered

Year clock

Aim is to make major release every year. In between aim is to make 3 smaller releases.

Release cycle

Release cycle

1 Major version x.0 will be released in January. 2 Version x.1. around March 3 version x.2. in September 4 version x.3. in November-December

Major features.

Major features cycle

Major feature concept making time is in spring. During the summer concepts are implemented, and testing and stabilizing time is in the autumn. Major fetures are released with version x.0.

Minor features can be released with minor releases x.1, x.2 or x.3. In addition to these, security fixes x.x.x are released whenever needed.

Automate and standardize

Automation enables you to do repetitive tasks without tying up valuable human resources. Standardizing ensures that your automation's inputs and outputs are consistent every time. We need to define structure and acceptance criteria for the deployable platform we are delivering.

  • What are the criteria?

Offer predictability

Intention is that we can offer some kind of roadmap and predictability for the participating companies. This is achieved by having public product backlogs for each version - past, current and future.

Version numbering scheme

Here's what we use: Major.Minor.Patch version .

The Major change involves a full release cycle, including marketing involvement etc.

Minor is changed when a new feature or a major behavior change is added to the product.

Patch version goes up by one every time a patch is officially added to the version, usually including bug fixes only.

See semver.org for more details

Versioned Product backlogs

  • Current version roadmap

  • older versions...

Stuff to see and merge into our model:

Clone this wiki locally