This section will help you understand the build versions, integration specifications, and menu specifications associated with each GLU.Engine. It also explains how to interpret the status of the build cycle and the build tagging system used in different environments.
GLU.Engine List
Upon accessing the application, you will see a list of GLU.Engines available to you. These will be displayed in the ‘GLU.Engine’ column. Each GLU.Engine may have multiple build versions associated with it.
Build Versions and Specifications
Every GLU.Engine is linked to one or more build versions. Each build version is connected to an Integration Specification and, optionally, a Menu Specification. The ‘Version’ column displays the available build versions for each GLU.Engine.
Status Column
The ‘Status’ column indicates the current status of the build cycle for each version. This helps you keep track of the progress of different builds.
Build Tagging System
It is crucial to understand the build tagging system used in GLU.Engines. Build versions for environments preceding the ‘Production’ Environment are tagged with the suffix ‘SNAPSHOT’. On the other hand, a final build ready for release to Production will be tagged with the suffix ‘RELEASED’. These tags help identify the state of a build version.
Spec Versioning
Please note that the build version is independent of the Integration and Menu Spec versions. Spec versioning allows you to maintain a history of configurations as your specs evolve over time. As specs may evolve independently of actual builds being promoted through your Software Development Life Cycle (SDLC), it is essential to pay attention to the build version and its associated specs when creating a build.
Importance for Docker Container Managers
For builds destined for Docker container managers, the ‘tag’ and name will apply. Ensure to keep track of the correct build version and its associated spec to avoid any confusion while deploying Docker containers.
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).
Follow the steps below to create a new Build as a User associated with a ‘Release Manager’ profile:
Step 1: Access the Build Creation Page by logging in to your account and navigating to the Build Manager screen. Locate the ‘Add Build’ button at the top of the screen and click on it to show the Build Manager dialogue. (Note. if the Add Build button does not exist, this means there all the builds accessible to the user are displayed on the screen already.)
Step 2: Select the GLU.Engine from the list of Applications associated with your profile which will be displayed. If your User profile is linked to a single GLU.Engine, that specific GLU.Engine option will be presented automatically. Choose the relevant GLU.Engine with which you want to associate the new Build.
Step 3: Define Build Version Increment Upon selecting the GLU.Engine, the Build creation screen will appear. Here, you can define the Build version increment by adjusting the MAJOR and MINOR version numbers. Ensure you choose the appropriate version increments for your new Build.
Step 4: Select MENU VERSIONS and INTEGRATION VERSION Specifications Next, select the associated Menu and Integration Specifications relevant to your Build. These specifications will determine the functionalities and integrations that your Build will include.
Step 5: For Container Manager Builds If you are building for a container manager, you need to add the DOCKER SERVICE NAME for the docker instance. Please refer to the ‘GLU.Engine Settings’ documentation for instructions on setting the docker credentials correctly.
Step 6: Confirm and Create Build Review all the selected options and configurations to ensure they are accurate. Once you are satisfied, click the ‘Submit’ button to initiate the Build creation process. The system will begin generating the new Build, and you will receive a confirmation message upon successful creation.
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 the configuration files associated with the GLU.Engine. These files can be swapped for the files included in a build which will allow for direct changes to the GLU.Engine without requiring a complete rebuild, reducing the possibility of introducing untested modifications.
The download will generate a zip file which will include the following configuration Files:
- application.yml
- camel-context.xml
- flows.json
- pom.xml
- loggingSetting.xml
- swagger.json
- OPTIONAL menu.json (depending on whether USSD menu spec is included.)
- OPTIONAL ISO8584( depending on whether building for an ISO connection.)
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’.
