Versions Compared

Version Old Version 1 New Version 2
Changes made by

Halvard Meijer

Halvard Meijer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Excerpt

Release types


  1. Main
Release​Intermediate
  1. Release​
  2. Patch Release ​​

Main Release ​

​

  1. Main releases are used to introduce significant extensions to our products. ​
  2. For Adonis Personnel Manager and Adonis Personnel Portal we have 6 main releases per year ​
  3. Main Releases are planned every 2 months ​
  4. Each   main   release  has a  number   of   tickets   assigned   based   on   available   development   resources  and estimations ​
  5. Each release has a landing zone for the delivery, which is usually the second or the third week of  every two months. ​
  6. The  customers   receive  an email  notifications   when   main   release  is  ready  for  install . The email  notification   contains  the release notes so the customers could see what is included. ​

​

Adonis Web Recruitment, Adonis Replicator, Adonis Timeclock, Adonis Plugins may have different  number of releases per year as this is defined by the lower number of changes we have to address in  these products ​

Patch Handling ​

Intermediate release​

  • Used to deliver critical functionality for the customers, when it was planned for previous main release but did not make it in the final.​
  • May be used by the customers to test new functionality prior to next main release.​
  • May be used in production by the customers if tested on their environments ​
    • No patches maintenance for intermediate releases.

    ​Adonis Support create jira issues from the ConnectWise tickets reported by the customers ​

    1. Adonis Support prioritizes each of the issue as per low->medium->high->highest scale ​
    2. Each of the highest priority issues are reviewed on development meeting not later than 1  working day after creation ​
    3. Development board decides on the issue assignment for the patch or one of the main  releases based on the priority, work arounds availability, product road map and complexity ​
    4. Most critical bugs are assigned to a patch releases, evaluated and scheduled for the nearest  possible release date ​
    5. Patches are only applied for the main releases ​


    Planning the release ​

    Resource planning ​


    1. analyze available development resources ​
    2. plan amount of working days ​
    3. check the holidays, days off, vacations, average sick leave days inside release period ​
    4. forecasting of repeating activities that are not actual development. Daily stand ups, releases planning  activities, 3rd line support, other projects involvement for developers assigned to the product release ​
    5. forecasting  the  " hands-on -keyboard" time  of   the   developers   withing   the   release ​


    Release scope ​

    ​

    1. Match  hands-on -keyboard time to  the  total  amount   of  time  estimated   by  developers  for  the   issues  in  release ​
    2. Finalize the release scope to
    allign available
    1. align available resources and estimations  based on issues priorities  ​
    2. Define the list of issues to be delivered within the release ​
    3. Assign issues that are not getting into current release to one of the  upcoming releases ​
    Planning Quality Assurance​


    Release Numbering ​

    QA before

    Format of the release

    ​

    Planning

    1. We plan 30% of a time needed for development to be additionaly spent for the QA​
    2. QA is executed in parallel with the development ​
    3. We freeze the development 2 weeks prior release date to execute regression testing and address the issue found in a QA​

    ​​

    QA includes:​

    1.  Manual testing​
    2. Automation testing
    3. Regression testing​

    Patch Handling​

    ​Patches for the critical bug fixes​

    ​Adonis Support create jira issues from the ConnectWise tickets reported by the customers​

    1. Adonis Support prioritizes each of the issue as per low->medium->high->highest scale​
    2. Each of the highest priority issues are reviewed on development meeting not later than 1 working day after creation​
    3. Development board decides on the issue assignment for the patch or one of the main releases based on the priority, work arounds availability, product road map and complexity​
    4. Most critical bugs are assigned to a patch releases, evaluated and scheduled for the nearest possible release date​
    5. Patches are only applied for the main releases​
    Release Versions​

    numbering is as follows:  

    yyyy.rr.pp

    yyyy year the development started

    rr: Release number 10 to 60, 6 releases per year

    pp: Patch number, patch 1 is the main release, 2 or higher are patches containing corrections. 


    ​Main Releases

    2019.10, 2019.20 ... 2019.60  ​

    Intermediate Releases:

    2019.11, 2019.21 ... 2019.61, 2019.62 ​

    ​Patch  Releases:

    2019.10.1.2 (Patch 1 for Release 2019.10.), 2019.20.1.6  (Patch 5 for release 2019.20) ​



    .