Skip to Content
Last modified by Danniar Firdausy on 2024/09/18 14:37
From version 3.1
edited by eMagiz
on 2022/06/10 10:42
Change comment: There is no comment for this version
To version 7.1
edited by Erik Bakker
on 2022/08/30 08:23
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.eMagiz
1 +XWiki.ebakker
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -3,9 +3,6 @@
3 3  
4 4  Should you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 -* Last update: August 4th, 2021
7 -* Required reading time: 6 minutes
8 -
9 9  == 1. Prerequisites ==
10 10  
11 11  * Basic knowledge of the eMagiz platform
... ... @@ -17,24 +17,22 @@
17 17  Auditability is defined as follows: A history trail that depicts who changed what at which moment in time containing an explanation of what has been changed
18 18  
19 19  * The key aspects are:
20 - * The description is your way of communicating the history of the flow
21 - * Using vague descriptions (or placing a dot as description) hurts the auditability
22 - * For all things versioned in eMagiz it is crucial that you supply the correct description
23 - * eMagiz provides audit trails on Architectural overviews (Design and Deploy architecture) including a description
24 - * eMagiz provides audit trails on message definitions and transformations including a description
17 + ** The description is your way of communicating the history of the flow
18 + ** Using vague descriptions (or placing a dot as description) hurts the auditability
19 + ** For all things versioned in eMagiz it is crucial that you supply the correct description
20 + ** eMagiz provides audit trails on Architectural overviews (Design and Deploy architecture) including a description
21 + ** eMagiz provides audit trails on message definitions and transformations including a description
25 25  
26 -
27 -
28 28  == 3. Making clear what you changed (auditability) ==
29 29  
30 30  As you can imagine, there is a need to know what has changed when working with software tooling. By knowing you can assess the impact of your planned changes within the context of the integration data model. In this microlearning, we will look at what you can do to clarify what you changed within the eMagiz platform.
31 31  
32 32  * The key aspects are:
33 - * The description is your way of communicating the history of the flow
34 - * Using vague descriptions (or placing a dot as description) hurts the auditability
35 - * For all things versioned in eMagiz it is crucial that you supply the correct description
36 - * eMagiz provides audit trails on Architectural overviews (Design and Deploy architecture) including a description
37 - * eMagiz provides audit trails on message definitions and transformations including a description
28 + ** The description is your way of communicating the history of the flow
29 + ** Using vague descriptions (or placing a dot as description) hurts the auditability
30 + ** For all things versioned in eMagiz it is crucial that you supply the correct description
31 + ** eMagiz provides audit trails on Architectural overviews (Design and Deploy architecture) including a description
32 + ** eMagiz provides audit trails on message definitions and transformations including a description
38 38  
39 39  === 3.1 Versioning by users ===
40 40  
... ... @@ -46,15 +46,15 @@
46 46  
47 47  ==== 3.1.1 eMagiz Data Model ====
48 48  
49 -On the eMagiz data model level in Design, you can version your eMagiz Data model. By doing this you can register per the eMagiz data model what you have changed. If you want practical help in learning how you can version your eMagiz data model please check out this [microlearning](intermediate-defining-your-message-structures-audit-emagiz-data-models.md). Doing so is crucial in telling others now (and in the future) what you have changed and why you have changed that portion of the eMagiz data model.
44 +On the eMagiz data model level in Design, you can version your eMagiz Data model. By doing this you can register per the eMagiz data model what you have changed. If you want practical help in learning how you can version your eMagiz data model please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Defining message structures.intermediate-defining-your-message-structures-audit-emagiz-data-models.WebHome||target="blank"]]. Doing so is crucial in telling others now (and in the future) what you have changed and why you have changed that portion of the eMagiz data model.
50 50  
51 51  ==== 3.1.2 eMagiz Flows ====
52 52  
53 -On the eMagiz flow level in Create, you need to create a new flow version when you are satisfied with your changes (if any are needed). Note that eMagiz allows the ability to use temporary versions while developing. When using these do note that you need to create a definitive version at some point to prevent confusion now (and in the future). If you want practical help in learning how you can version your eMagiz flows please check out this [microlearning](crashcourse-platform-create-promote-flows-to-deploy.md). On the flow level, it must become clear to anyone what you have changed. That will determine whether a certain flow version is ready to be released much easier.
48 +On the eMagiz flow level in Create, you need to create a new flow version when you are satisfied with your changes (if any are needed). Note that eMagiz allows the ability to use temporary versions while developing. When using these do note that you need to create a definitive version at some point to prevent confusion now (and in the future). If you want practical help in learning how you can version your eMagiz flows please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-create-promote-flows-to-deploy.WebHome||target="blank"]]. On the flow level, it must become clear to anyone what you have changed. That will determine whether a certain flow version is ready to be released much easier.
54 54  
55 55  ==== 3.1.3 eMagiz Releases ====
56 56  
57 -On the eMagiz release level, you need to create a new version whenever you want to include new versions of flows in a release. There is one exception to this rule and that is when someone else has already created a new release that is not yet deployed or made active. In that scenario, you can both combine all changes that need to de deployed to create a more efficient deployment. With eMagiz releases, you have two ways of notifying others what the release is all about. The first one is the name of the release and the second one is the description of a release. If you want to learn how to create a release please check out this [microlearning](crashcourse-platform-deploy-create-new-release.md). If you want to learn more about managing releases please check out this [microlearning](intermediate-release-management-managing-releases-best-practice.md)
52 +On the eMagiz release level, you need to create a new version whenever you want to include new versions of flows in a release. There is one exception to this rule and that is when someone else has already created a new release that is not yet deployed or made active. In that scenario, you can both combine all changes that need to de deployed to create a more efficient deployment. With eMagiz releases, you have two ways of notifying others what the release is all about. The first one is the name of the release and the second one is the description of a release. If you want to learn how to create a release please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-create-new-release.WebHome||target="blank"]]. If you want to learn more about managing releases please check out this [[microlearning>>doc:Main.eMagiz Academy.Microlearnings.Intermediate Level.Release Management.intermediate-release-management-autoclean-releases.WebHome||target="blank"]].
58 58  
59 59  === 3.2 Versioning by eMagiz ===
60 60  
... ... @@ -65,8 +65,6 @@
65 65  
66 66  In all cases, you will find a History button on the page in question that will guide you to the history (audit trail) of what has changed by whom at which point in time.
67 67  
68 -
69 -
70 70  == 4. Assignment ==
71 71  
72 72  Check out the history of (one of) your eMagiz data models, one of your flows, and your releases to see if you can determine how they have changed over time.
... ... @@ -74,14 +74,12 @@
74 74  == 5. Key takeaways ==
75 75  
76 76  * The key aspects are:
77 - * The description is your way of communicating the history of the flow
78 - * Using vague descriptions (or placing a dot as description) hurts the auditability
79 - * For all things versioned in eMagiz it is crucial that you supply the correct description
80 - * eMagiz provides audit trails on Architectural overviews (Design and Deploy architecture) including a description
81 - * eMagiz provides audit trails on message definitions and transformations including a description
70 + ** The description is your way of communicating the history of the flow
71 + ** Using vague descriptions (or placing a dot as description) hurts the auditability
72 + ** For all things versioned in eMagiz it is crucial that you supply the correct description
73 + ** eMagiz provides audit trails on Architectural overviews (Design and Deploy architecture) including a description
74 + ** eMagiz provides audit trails on message definitions and transformations including a description
82 82  
83 -
84 -
85 85  == 6. Suggested Additional Readings ==
86 86  
87 87  If you are interested in this topic and want more information please check out the help texts provided by eMagiz.
... ... @@ -88,6 +88,4 @@
88 88  
89 89  == 7. Silent demonstration video ==
90 90  
91 -As this is a more theoretical microlearning we have no video for this.
92 -
93 -)))((({{toc/}}))){{/container}}{{/container}}
82 +As this is a more theoretical microlearning we have no video for this.)))((({{toc/}}))){{/container}}{{/container}}