Introduction
Ah, the much-anticipated sequel! Will it exceed the beloved original, like “The Godfather Part II”, or will it be a massive disappointment like “Hannibal”?!
This is a follow-up article to “Flow Genesis Terms I – defining Models and Snapshots“, so please read that article first to get the full perspective.
What is a Diagnostic Report?
The Diagnose tab in Flow Genesis allows you to automatically generate a list of common issues associated with any snapshot you have uploaded. This is a useful check to perform before deployment or UAT, as it can often catch errors that are difficult to detect with the human eye.
You can then save the list into a Diagnostic Report to keep a permanent record of issues found. The file created is referred to as a Diagnostic Report, and contains everything you can see on the screen when you diagnose a snapshot.
Once saved, you can also add Sticky Notes to explain or discuss errors with members of the team. This provides a useful method of collaboration to make sure things are not missed during any particular deployment.
It also provides a way for non-technical team leaders or project managers to verify that no issues exist that have not been sufficiently explained by the developer team.
Note the in the future, we will be adding a feature to export a Diagnostic Report into a more easily-readable issue-list document, so it’s worth saving reports now to take advantage of that additional feature when it becomes available.
What is a Template?
If you’ve ever worked on a multi-country or multi-department roll-out, chances are you’ve already thought about templating without realizing it.
Often when similar models are to be deployed in multiple places, the approach taken is to create one generic template model, then use that as a basis for deployment to the other areas. The generic model can be tested and verified by the customer first, before any area-specific customizations are carried out.
In Genesis, a Template refers to an abstracted Snapshot file which allows users to provide specific customizations for designated objects before deployment.
This is useful in POC development or when starting a project, as it gives you a pre-tested and risk-free starting point for any custom development without locking you into a particular naming standard.
The template file contains all the same data included in the Snapshot, along with instructions on how the template will behave when it is applied.
The output of applying a Template is a new Snapshot containing the customizations specified by the user. This Snapshot can be used to deploy a new server, or to upgrade an existing one with the new names.
We have big plans for the Templating feature of Genesis, including a wizard-based interface for many common customizations beyond naming, so it’s well worth investigating how it can help your business processes now.
What is a Deployment Package?
So you have your model completed, your Templates applied and your Snapshot files created… what next?
That’s where Deployment Packages come in. A Genesis Deployment Package is basically a list of instructions to carry out on a model to convert it from one state of development to another.
More simply put, it stores the differences between two Snapshots so that one can be automatically changed into the other.
The first step toward creating a Deployment Package is to perform a “diff”, or comparison between two Snapshots. Diff is a computing term for an operation that identifies differences between two files, in our case the two Snapshot files.
It is important to note that in almost all cases, the first Snapshot used as the basis for the Deployment Package should be a Snapshot of the server your are deploying to. This is to ensure all the generated instructions are valid for the target server. It is sometimes valid to violate this rule, but make sure you understand exactly what you are doing.
The second Snapshot should be the one that represents the new state of the target server.
So, for instance, if you have completed UAT on a staging server, and would like to deploy changes to production, the first Snapshot should be an up-to-date version of the production server, and the second snapshot should be an up-to-date version of the production server. This would result in a series of instructions that would implement all the recent development on the staging server into the production server.
When exported, Deployment Packages have the file extension .xdpd, which stands for “XML Deployment Package Document”. To perform the deployment, you can load the generated file into the Flow Model Packager.
Conclusion
I know sequels are often more convoluted and confusing that the original, so I guess there is a little “sequelitis” happening here!
Hopefully this gives you a better understanding of the terms and features used in Genesis and how you might apply them to your business. Trust me, once you’ve mastered Diagnosis, Templating and Deployment the Genesis way, you’ll wonder how you ever did without it!
Any questions, feel free to use the comments in this article.