Autoclean releases

{{container}}{{container layoutStyle="columns"}}(((

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.

4

5

Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].

6

7

== 1. Prerequisites ==

8

9

* Intermediate knowledge of the eMagiz platform

10

11

== 2. Key concepts ==

12

13

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.

14

15

16

== 3. Autoclean mechanism explained ==

17

18

=== 3.1 Managing releases manually ===

19

20

The best practices for managing releases are:

21

** Keep the list of releases short and clear

22

** When creating a new release determine whether an old one is a deletion candidate

23

** Preferably use the same release across environments to prevent copy+paste mistakes

24

25

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.

26

27

[[image:Main.Images.Microlearning.WebHome@intermediate-release-management-management-releases-best-practice--release-overview.png]]

28

29

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.

30

31

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:

32

33

[[image:Main.Images.Microlearning.WebHome@intermediate-release-management-management-releases-best-practice--release-overview-managed.png]]

34

35

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

36

37

=== 3.2 Cleaning rules ===

38

39

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

40

41

1. Firstly, verify Major branches

42

* There will be always 1 active, major release

43

* There will be always 1 major release next to the active major

44

2. Secondly, verify the Minor across all branches

45

* There will be always 1 active minor release

46

* There will be always 2 minor releases across all branches beyond the active minor

47

* The minor for an saved major releases will be preserved regardless

48

3. Thirdly, verify the Patches across all branches

49

* There will be always 1 active patch release

50

* There will be always 3 patch releases across all branches beyond the active patch

51

* The patch for an saved minor releases will be preserved regardless

52

* The patch for an saved major releases will be preserved regardless

53

4. No-active releases with versions higher than the active will be not be regarded

54

55

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

56

57

[[image:Main.Images.Microlearning.WebHome@intermediate-release-management-autoclean-releases-1.png]]

58

59

=== 3.3 Impact adding a major releases ===

60

61

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

62

63

* Red : releases removed

64

* Green : release added

65

* The entire major branche of version 1 is removed as that violates the rule for the major branche evaluation.

66

67

[[image:Main.Images.Microlearning.WebHome@intermediate-release-management-autoclean-releases-2.png]]

68

69

=== 3.4 Impact adding a minor releases ===

70

71

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

72

73

* Red : releases removed

74

* Green : release added

75

* Adding a minor would evaluate whether a major needs to be removed or not - check rule 1 major + 1 major active

76

* Adding a minor would evaluate whether a minor needs to be removed or not - check rule 2 minor + 1 minor active

77

* 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.

78

79

[[image:Main.Images.Microlearning.WebHome@intermediate-release-management-autoclean-releases-3.png]]

80

81

=== 3.5 Impact adding a patch releases ===

82

83

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

84

85

* Red : releases removed

86

* Green : release added

87

* 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.

88

89

[[image:Main.Images.Microlearning.WebHome@intermediate-release-management-autoclean-releases-4.png]]

== 4. Assignment ==

Check out if the best practices detailed above are applied within your (Academy) project. If not open up a discussion on why those choices are made to learn from that.

94

95

== 5. Key takeaways ==

The key takeways are

* Releases are automatically clean for users so that there is maximum number of releases available

100

* Cleaning of releases happens at the moment when a release is created (not at the moment when it's set as active)

101