By using the applicable ‘Manage Analyst DoD’ the Release Manager can define any number of specific criteria that the Analyst will be required to confirm as having been ‘done’ for that particular build. A different DoD list can be defined for the QA team.

The sample below shows the DoD for the Analyst.

The Analyst / Tester is prompted to ‘tick’ each DoD task prior to progressing the workflow to the next stage. These DoD results form part of the ‘Build History’ and Audit trail for every GLU.Engine ever built. This serves to establish sound discipline within the team using the GLU.Console.

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.Engines’ 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 Version’ and, optionally, a ‘Menu Version’. The Versions 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. Case is important.

i.e. autotest:1.0-SNAPSHOT

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:

1. application.yml
2. camel-context.xml
3. flows.json
4. pom.xml
5. loggingSetting.xml
6. swagger.json
7. OPTIONAL menu.json (depending on whether USSD menu spec is included.)
8. 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’.

A Column exists ‘Java’ which describes the Version of Java which the GLU.Engine was built for.

The GLU.Engine Settings interface provides analysts with the capability to define a set of parameters utilised by the GLU.Engine during operation. These settings regulate the GLU.Engine’s interaction with the operational environment.

To configure the settings, activate the ‘GLU Engine Settings’ button and select the desired environment to specify the settings for.

Choose the GLU.Engine required and the GLU.Engine Settings page will open on the General tab. 

Navigate the tabs and choose the settings to change. The following settings can be changed:

• General settings:
  • Server Port
  • switch spring JMX Enabled
  • switch jolokia debug Mode Active
  • switch Management Endpoint Shutdown Enabled
• Logging level and parameters
• Docker settings:
  • switch on docker usage and distribution
  • all associated docker parameters if docker is switched on
• Provision customised settings for the GLU.Engine
• Adjust the JVM settings which the GLU.Engine utilises

General tab

The Server Port or Management Port (used interchangeably) in the context of JMX metrics refers to the port number used for communication between JMX client applications and the JVM (Java Virtual Machine) management interface. JMX (Java Management Extensions) is a Java technology that provides a standard way to monitor and manage Java applications and resources. The JMX Management Port allows remote monitoring and management of a running Java application through JMX client applications. JMX client applications can use the Management Port to connect to the JVM and retrieve information about the application, such as memory usage, thread counts, and performance metrics, as well as perform management operations, such as garbage collection and thread dumps. The Management Port is specified as a command line argument when starting the JVM and its default value is typically set to 9010.

The Server Port field can be set to control which port the GLU.Engine Management APIs use. The server port must be unique for each GLU.Engine running on a server therefore it is important to change the server port if you plan to run multiple GLU.Engines on the same server. If you don’t change the port for each such GLU.Engine, you’ll have conflicts when trying to startup the GLU.Engine. 

The Management Endpoint JMX Domain is used to set the URL for the JMX Domain.

Use the tick boxes to: 

• switch Spring JMX to be enabled, this will enable JMX Metrics to be available on the set JMX Domain via the Server Port.
• switch Management Endpoint shutdown to be enabled. (This setting exists to provide an extreme level of security for the shutdown of GLU.Engines, if enabled then the API will work and you can shutdown the GLU.Engine from the API call. Shutdown API Call)

Note that if your Application Settings have the path for logs set to a sub-folder within the GLU.Engine folder if / when you deploy a new build you will lose / over-write your logs if you’ve not moved them. So in Application Settings, the recommendation is to set the path to a folder outside the GLU.Engine folder. 

For the details on setting the name of the Log file GLU.Engine Log Name.

Logging tab

For details on log levels settings see GLU.Engine Logging Levels.

For details of each of the settings in the log tab please refer to  GLU.Engine Logs.

Docker tab

It is possible to switch on the use of Docker and set the Docker settings which are used to push a docker container to a container registry. All fields are mandatory. 

For some container registry systems like Azure when the  docker image repository doesn’t exist, then it will be created when GLU pushes to the container registry. 

For more information on the docker settings please refer to GLU.Engine running in Docker.

Custom Settings tab

Where required it may be necessary to set up customer parameters for using with the GLU.Engine. If this is required these settings can be configured in this tab.

JVM tab

The JVM Arguments are set to the default arguments for running the Java Virtual Machine which runs the GLU Engine, however with access to these settings it is possible to refine the settings as required to optimise the performance of the GLU.Engine. 

Please refer to  GLU.Engine – Performance-Level Settings for details of how the changes will affect the GLU Engine.

The JVM Arguments will be applied to docker as well if the GLU.Engine is to be hosted in docker. The following extract shows how the JVM settings can be viewed using the docker exec command. Use command docker ps to view the containers:

root@ip-172-31-52-133:~# docker ps
CONTAINER ID   IMAGE                                       COMMAND                  CREATED         STATUS         PORTS                                                                  NAMES
4e71043cef89   gluglobal/glu_data:1.0-SNAPSHOT             "java '-Djava.securi…"   5 minutes ago   Up 5 minutes   9088/tcp, 9195/tcp                                                     data_autoTest.1.4g03oc84p4kbt5b1a8waj5n3y
5

docker exec -u 0 {CONTAINER ID} ps -ef to see the java call.

root@ip-172-31-52-133:~# docker exec -u 0 4e71043cef89  ps -ef | grep java
    1 root       0:55 java -Djava.security.egd=file:/dev/./urandom -XX:+PrintGCDetails -Xloggc:gc.log -Xms2g -Xmx2g -XX:+UseG1GC -XX:MaxGCPauseMillis=250 -XX:+UseStringDeduplication -XX:G1HeapRegionSize=32 -XX:G1ReservePercent=15 -XX:InitiatingHeapOccupancyPercent=30 -XX:MetaspaceSize=100M -jar /glu_data-1.0-SNAPSHOT.jar --logging.config=./engine/config/loggingSetting.xml
root@ip-172-31-52-133:~#

Symantec Version Controls are supported to ensure evolving GLU.Engine builds are traceable and properly version controlled and tagged. In addition, any built GLU.Engine that is for an Environment that is not flagged as the ‘Production’ environment will be tagged as a ‘SNAPSHOT’. If the built GLU.Engine is for Production deployment it will be tagged as ‘RELEASED’. The version control will then need to be incremented to make changes to a ‘RELEASED’ GLU.Engine.

The .JAR can be deployed into the Clients own Docker container or a .JAR file as a Springboot contained executable can be deployed to a server or VM.

The Test Cycle defined by the Release Manager will dictate the sequence of Environments that any particular build process will follow. The Build Manager tracks the SDLC sequence of each build doing so ensures that the applicable API / Connector environment HOST parameters are included in the build. This eliminates the need for a DevOps engineer to manually apply End-Point IP address / URL parameters to the deployed GLU.Engine. Rather all those parameters are natively included in the build by the Build Manager.

The built component can then be downloaded and deployed into the applicable server depending on the stage of the SDLC process for that particular build.

All builds going back in time are stored by GLU with full version history visible, older builds are securely archived into GLU’s long-term archive and can be retrieved via Support Desk Request.

The Build Manager has an ‘GLU.Engine Settings’ configuration panel that enables the definition of various configuration settings for any specific build to be included in that build. See the screenshot example below.

Logging related settings such as log levels, log file locations and log file names can be defined.

It is possible to set the path of the log files such that if run from a docker image it is possible to configure the volume in the docker-compose file to redirect the path and file defined in the console to a volume outside the container image.

i.e.

    volumes:
       - /var/log/gluEngineName/gluware.log:/log/gluware.log

Java Management Extensions (JMX) properties are available through the GLU.Engine APIs. JMX provides a standard mechanism to monitor and manage applications. By default Spring Boot will expose management endpoints as JMX MBeans under the org.springframework.boot domain however since

If your application contains more than one Spring ApplicationContext you may find that names clash. To solve this you can set the endpoints.jmx.unique-names in the GLU ‘Application Settings’ property to ‘true’ so that MBean names are always unique.

If you don’t want to expose endpoints over JMX you can set the endpoints.jmx.enabled property to ‘false’.

Jolokia is a JMX-HTTP bridge giving an alternative method of accessing JMX beans. With Spring Boot you can use your application.properties, simply prefix the parameter with jolokia.config.debug property to ‘true’.

For additional detail on JMX monitoring see this resource.

Actuator endpoints allow you to monitor and interact with your GLU application. Spring Boot includes a number of built-in endpoints and you can also add your own. For example, the health endpoint provides basic application health information on your Application.

Click here or additional detail.