The list of GLU.Engines available for the user will be shown in the ‘GLU.Engine’ column. Associated with each GLU.Engine, any number of build Versions can be displayed. Each Version is associated with an Integration Specification and potentially also a Menu Specification. The ‘Status’ column indicates the current status of any build cycle.
It is important to note that the Build Version is associated with a build ‘tag’ – for all builds for Environments pre-ceding the ‘Production’ Environment, the build will be tagged with the suffix ‘SNAPSHOT’. A final build for release to Production will be tagged with the suffix ‘RELEASED’.
NOTE that the Build version does not necessarily correlate to the Integration or Menu Spec versions. The ‘spec’ versioning provides a means of retaining a history of configurations as your specs evolve. Since those may evolve independently of actual builds being promoted through your ‘SDLC’ it it important on the Build Manager dashboard to always take note of what build version and associated ‘spec’ you are created in a build for. This is especially important for builds to docker container managers as the ‘tag’ and name will apply.
To create a new Build, as a User associated with a ‘Release Manager’ profile, click on the ‘Edit / Increase Version’ button, select the Application with which you want the build to be associated (note if your User profile is only associated with a single Application, only that Application option will be presented). Then the screen below will appear. Define the Build version increment applicable by adjusting the Major and Minor version numbers, and select the associated Menu and Integration Specifications. If you are building for a container manager add the docker service name for the docker instance (see GLU.Engine Settings for setting the docker credentials).
Then click on ‘Submit’.
The newly created Build will reflect on the Build Manager home screen with a status of ‘Analysis Phase’. Users associated with the ‘Analyst’ profile will receive an email notification to indicate that the Release Manager has created a new build requiring Analysis.
Actions
These are the ‘Actions’ in the drop-down menu.
The ‘Edit/Increase Version’ presents the same screen as for the ‘Add New Build’ but in this case the screen is an ‘Edit Build’ screen.
The ‘Delete’ option will present a confirmation screen to confirm that the selected Build Version should be deleted.
The ‘Download’ option will present a pop-up with the history of builds that have been created. Note that typically only the QA team can create a build, as such normally the Analyst would not have the permissions to create a build or to download a build.
The ‘Send DoD’ option at this point in the workflow (Analysis Phase) will present the Analyst DoD with a set of check-boxes for the Analyst to indicate which items on the DoD list have been done.
Upon clicking ‘Send’ an email will be triggered to the Release Manager to highlight the Analyst’s job completion and the associated DoD record. Thereafter the status will change to ‘Awaiting Approval’.
One-Click Builds
This button to the left of the ‘Action’ button can be used to create a ‘one-click build’. It will create the build for the Environment specified in the ‘Environments’ column. The environment in the environment column is the last environment build attempted and represents the environment that was built for, which can be seen at the top of the GLU.Engine Download Manager screen. If the build failed the environment will still be shown. However, if the build failed due to a problem with the configuration setup of the environment, then a warning will be present instead in the column.
History
The ‘History’ option will show the life of a GLU.Engine with all build manager actions (including DOD results) which have been carried out against the GLU.Engine.
Workflow: ON
If Workflow is ‘ON’ for a GLU.Engine, the Release Manager Action options are slightly different to those for the Analyst of QA Roles. For example, ‘Approve Testing’ will promote the build to the next step in the SDLC and the QA Team will be notified that a build is ready to be created and tested. ‘Reject DoD’ will return the build to ‘Analysis Phase’ for the Analyst to complete whatever critical steps are pending based on the DoD.
The ‘Build’ action will trigger the build of the GLU.Engine. This build will embed within it the Environment parameters applicable to the relevant stage in the SDLC that this build is at e.g. Testing / Pre-Prod etc. Alternatively, the QA User can create a build for a specific environment in which case a pop-up will present the available pre-defined environments as below. You have the option to add a Release Note to each Build, this is recommended to help keep track of changes being made.
Download Configuration
The Download Configuration button in the Build Manager pop-up (which appears after clicking the ‘Build …’ action option under the Actions menu) provides a solution that allows for direct changes to the GLU.Engine without requiring a complete rebuild, reducing the possibility of introducing untested modifications.
The download will include the following configuration Files:
- application.yml
- camel-context.xml
- flows.json
- iso8583
- loggingSetting.xml
- menu.json
By exposing these configuration files, system administrators gain direct access to the GLU.Engine’s core settings. This enables them to make necessary adjustments without the need for rebuilding the engine, mitigating the risk of introducing untested changes during production.
This capability improves the flexibility and efficiency of managing the GLU ecosystem and SDLC. Users can now make targeted modifications to the GLU.Engine’s configuration files as needed, ensuring a streamlined development and deployment process.
Please note that any modifications made to these configuration files should be carefully tested and reviewed before deploying them in a production environment.
GLU.Engine Download Manager screen
Once a build is created, the ‘Download’ action will present a list of previous builds that have been created. The ‘Download’ link will result in the GLU.Engine package being downloaded to the QA Users local downloads folder from where it can be deployed to the GLU.Engine server. If a build fails for some reason, the Build Error will show as per the example in the screenshot below.
Once the Workflow has reached the Production point, you will need to complete a RELEASE to get the final build of the GLU.Engine, which is classed as the RELEASE and should be the GLU.Engine which is taken to production.
If however for some reason you are not ready to go to RELEASE, it is possible to cancel the release. With the ‘Cancel Release menu option’.
