Autoclean releases
In early 2022, eMagiz introduced an automated process to streamline the cleanup of releases in the Deploy phase. Before this update, users had to manually delete old releases, which, if neglected, could cause performance issues in the Portal. With this new functionality, the platform automatically limits the number of preserved releases, ensuring optimal system performance and ease of management. We will explore more on this functionality in this microlearning.
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.
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:
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
- Firstly, verify Major branches
- There will be always 1 active, major release
- There will be always 1 major release next to the active major
- 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
- 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
- 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
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 branch of version 1 is removed as that violates the rule for the major branch evaluation.
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 branch results in the cleanup of the entire major branch 1 and removing all patches in the oldest minor branch. 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.
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 branch are evaluated to check for 1 active releases + 3 previous patches in that branch. 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.
4. Key takeaways
The key takeways are:
- Releases are now automatically managed, ensuring a maximum number of active releases are maintained without requiring manual intervention.
- The automatic cleanup process helps maintain optimal performance by removing outdated releases at the time of creation, not just activation.
- Utilize versioning effectively to track and manage releases across different environments, ensuring clarity and reducing the risk of errors.
5. Suggested Additional Readings
If you are interested in this topic please read the help text eMagiz provides you in the container section in the Deploy phase and see the following link: