Autoclean releases

Last modified by Erik Bakker on 2023/09/08 11:34

eMagiz has implemented an approach since early 2022 to automatically the releases inside the Deploy phases. Up until early 2022, releases had to manually be deleted and failure to do so resulted in reduced performance in the specific section of the Portal. With this functionality, there will be a maximum number of releases preserved for users and releases are automatically removed from the model.

Should you have any questions, please contact academy@emagiz.com.

1. Prerequisites

  • Intermediate knowledge of the eMagiz platform

2. Key concepts

A release in eMagiz holds the key information what flows are to be deployed in what environment exactly. In the release, you will find the specific flows with the relevant version information listed, added with key flows that are required to make the release active. Active means that the release can be deployed effectively. Each release will have a distinct name to indicate the change made in the release, as well as a version. That version is based on the idea of having major, minor and patch releases. Condusive with the general way of working on IT. In the approach taken by eMagiz to clean releases, we have leveraged these version indicators to find out what the older releases are.

3. Autoclean mechanism explained

3.1 Managing releases manually

The best practices for managing releases are:

    • Keep the list of releases short and clear
    • When creating a new release determine whether an old one is a deletion candidate
    • Preferably use the same release across environments to prevent copy+paste mistakes

You can check out the overview of releases when you navigate to Deploy -> Releases. On the right-hand side of the page, you will see all releases that still exists within your context.

intermediate-release-management-management-releases-best-practice--release-overview.png

This release overview tells how many releases you have created but not yet deleted. Furthermore, it gives information on what the release is about, on which environment it is active and for which environments it has been approved. In the example shown above, we see that the latest release is active in both Test and Acceptance. Some large projects in which multiple teams work on completely different sets of integrations. In those scenarios, we advise using separate releases per environment to limit the risk of deploying flows too early or too late to a certain environment.

What we can also learn from the picture shown is that we have three releases of which two are not active and are older compared to our active release. This means that the oldest one is a deletion candidate. As a rule of thumb, we like to adhere to the best practice that you should always keep one release in the bag per environment. So at a maximum, you should have six releases on this list. The dream scenario would be that you build everything the first time right which means you only need one release. If we apply our own set of management rules to our release overview the result will be:

intermediate-release-management-management-releases-best-practice--release-overview-managed.png

The above illustrates how Releases can be cleaned up. The platform itself has autoclean mechanisms in place to ensure the list remains manageable.
  

3.2 Cleaning rules

Below are the general rules that are applied to locate a release that can be deleted from list. It's probably easiest to understand to regard these rules in the form of a graph or decision tree. In the following sections you will find an example

  1. Firstly, verify Major branches
  • There will be always 1 active, major release
  • There will be always 1 major release next to the active major
    2. Secondly, verify the Minor across all branches
  • There will be always 1 active minor release
  • There will be always 2 minor releases across all branches beyond the active minor
  • The minor for an saved major releases will be preserved regardless
    3. Thirdly, verify the Patches across all branches
  • There will be always 1 active patch release
  • There will be always 3 patch releases across all branches beyond the active patch
  • The patch for an saved minor releases will be preserved regardless
  • The patch for an saved major releases will be preserved regardless
    4. No-active releases with versions higher than the active will be not be regarded

Starting point for the section below is the following state of the releases in Deploy

intermediate-release-management-autoclean-releases-1.png

3.3 Impact adding a major releases

When adding a new major releases AND making that release active, the following will happen:

  • Red : releases removed
  • Green : release added
  • The entire major branche of version 1 is removed as that violates the rule for the major branche evaluation.

intermediate-release-management-autoclean-releases-2.png

3.4 Impact adding a minor releases

When adding a new minor releases AND making that release active, the following will happen:

  • Red : releases removed
  • Green : release added
  • Adding a minor would evaluate whether a major needs to be removed or not - check rule 1 major + 1 major active
  • Adding a minor would evaluate whether a minor needs to be removed or not - check rule 2 minor + 1 minor active
  • In the example below, the addition of a minor in the major 3 branche results in the cleanup of the entire major branche 1 and removing all patches in the oldest minor branche. Furthermore, once the new minor is made active there will be an additional minor active beyond the 1 active + 2 minor. An addition of a patch or major could result in a cleanup of minors as well.

intermediate-release-management-autoclean-releases-3.png

3.5 Impact adding a patch releases

When adding a new patch releases AND making that release active, the following will happen:

  • Red : releases removed
  • Green : release added
  • Once a new patch is created, all patches in the major branche are evaluated to check for 1 active releases + 3 previous patches in that branche. Making that same new patch active means that there are 5 patches present. An addition of a minor or major could result in a cleanup of patches as well.

intermediate-release-management-autoclean-releases-4.png

4. Key takeaways

The key takeways are

  • Releases are automatically clean for users so that there is maximum number of releases available
  • Cleaning of releases happens at the moment when a release is created (not at the moment when it's set as active)
  • Leverage the versioning of releases to incidate what release is on what environment.

5. Suggested Additional Readings

N/A