Skip to main content
Version: 2.1.0

Release Packages

AGIL Ops Hub releases consists of the following:

These release artifacts are made available privately via GitHub Packages, and GitHub Source Code Repositories. Please approach one of our friendly AGIL Ops Hub team members to for access.

Although possible, it is not recommended to have all your project team members directly access the AGIL Ops Hub Private Package Registry, and Source Repository for those artifacts for both development and production.

Instead, your project should designate a representative (i.e. Configuration Manager) to review and move only the required artifacts into your project's own SCM (software configuration management) ecosystem (probably consisting of an artifact registry and source code version control system).

The rest of the project members should only access your project's own artifact registry and source repository for the required artifacts.

This allows for better dependency management within your project. Furthermore, your project's Docker Compose configuration files and web application source code will need to be updated based on your project's own needs. These modified files should be version controlled in your own source/version control system.

Container Images​

All AGIL Ops Hub modules, except Web Base, will have container images for the backend services. Some may also have container images for a frontend web application.

caution

Container images provided are Linux containers for the x86-64 architecture.

Please approach the AGIL Ops Hub team if you require containers to be built for other operating systems or instruction set architectures (such as Windows or ARM).

The container image for backend services are intended to be used as is, for both development and production.

As for the frontend web app containers, they contain the pre-built Web Base bundled with the respective Web Components from the module; these frontend containers are typically ready-to-use consoles, which serve as platforms for us to validate and test our modules. These containers are not intended for production use.

Typically, projects would install a few modules' web components into single one Web Base, modify the Web UIs to follow their own specific UI/UX and design, and then build them into their own container image for production use.

note

More details on the Web Base will be covered later in its own section.

As mentioned, projects should review and transfer the container images of the desired modules to their own Container Registry.

In general, the steps to transfer the container images into a Container Registry will involve:

  • Pulling the container images using Docker or Podman
  • Re-tagging the images
  • Push the images into the project's Container Registry

For projects with air-gap requirements, the steps should be as follows:

  • Pull the container images using Docker or Podman in a secure, Internet-connected machine
  • Export the container images into tar archives using the save command in Docker or Podman
  • Move the tar archives into the air-gapped environment
  • Load the container images back into Docker or Podman from the tar files
  • Re-tag the images
  • Push the images into the project's Container Registry

Docker Compose Files​

AGIL Ops Hub also releases a set of corresponding Docker Compose configuration files to run our containers in Docker or Podman engine. This allows developers to quickly and easily set up a local development environment.

danger

The Docker Compose configuration files are intended to be used to deploy containers in Docker or Podman engine for development purposes only!

It is not recommended to deploy containers in Docker or Podman engine for production, except for small scale projects that only have a handful of containers and with no high-availability (HA) requirement.

For most projects, it is recommended that you use Kubernetes or some other suitable container orchestration platform (e.g. Docker Swarm or Amazon Elastic Container Service).

As production deployment environments vary wildly across projects, it is not possible to provide a standard set of deployment manifest files. AGIL Ops Hub team will instead work with the project to craft the manifest files for the specific target environment.

The Docker Compose configuration files are published in the dev-containers repository.

The steps to move those files to your project's own SCM would typically be:

  • Download the dev-containers repository as zip
  • Unzip to your local machine
  • Review and modify the files based on your project's and environment's needs
  • Add the modified files to the project's source code repository for version control and distribution amonst project members

Node Packages​

AGIL Ops Hub also releases node packages for:

  • Module Web Components

    These are special node packages that can must installed into Web Base using Web CLI tool. This allows the project to only add (install) each module's web components that are needed by the project.

  • Web CLI Tool

    The Web CLI Tool that is used to install Module Web Components is itself a node package which will be installed when the Web Base is initialized.

  • Web Libraries

    These are reusable libraries to simplify web development. Currently, it contains:

    • Logger - logging library for both Web frontend (at browser console) and Web backend (at container) logging.
    • SSE Client - to simplify writing server-send events (SSE) code on the frontend.
    • GraphQL Client- facilitate access GraphQL APIs from frontend.

Generally, the steps to move the node packages to your project's artifact registry is as follows:

  • Install the package at the specified version using the npm install command.
  • Set npm to point to the project's registry using the npm config set command.
  • Publish the package to project registry using the npm publish command.

Source Code Packages​

AGIL Ops Hub publishes source code packages for:

  • Web Base

    Web Base is a scaffold SvelteKit project that provides a skeleton application to kick-start web development using AGIL Ops Hub. For more information, refer to the Web Base section.

  • Workflow Activity Template

    The Workflow Activity Template is a scaffold golang project that provides template project code to kick-start workflow activity development using golang. For more information, refer to the Workflow Activity Development Section.

  • Workflow Studio

    Workflow Studio is the web application that allows users to design and configure workflows. Projects can directly use the pre-built Workflow Studio container for deployment. If customize of the Workflow Studio is required, the source code is also available.

These source code packages can be access from the respective repositories on GitHub. Projects should download the source code as zip files and upload them into their respective SCM as necessary.