Documentation

⚲
No results
    gitHub

    Table of contents

    DevOps CI/CD architecture

    In the How-To Guide Integrate CLI with DevOps CI/CD pipelines, we detail a Governance-first use case to illustrate the power and flexibility of the Command-Line Interface.in the context of our Metadata-as-Code strategy.

    CLI governance-first use case

     

    Let's describe here the architecture setup to support this use case, and others as well.

     

    The setup assumes that:

    - data models are stored in your Git repository

    - you have an instance of Hackolade Studio ready to run in Docker containers, as documented here, and allowing you to run in multi-threaded mode.  The instance running the Hackolade Studio Command-Line Interface in Docker requires a license key, which must be a Professional (or Workgroup) Concurrent key.

    - you create Git repository provider triggers for your use case (GitHub Actions, Bitbucket pipelines or equivalent.)

     

    The diagram below shows a simple architecture leveraging Hackolade Studio CLI in Docker containers::

     

    Image

     

     

    Below is a description of the process steps for the above diagram:

    1) users maintain data models in Hackolade Studio

    2) users commit and push new model versions, possibly merging a pull/change request to the main branch, possibly with a tag to mark a new release

    3) an event-driven trigger has been created to execute the orchestration of a set of successive CLI operations (may also include git commands and OS commands)

    4) the first command is to reverse-engineer the database instance.  This could be done with different instances (for example dev, test, acceptance, prod) to keep them in sync, but maybe at different times, based on branch lifecycle.

    5) the repo is pulled locally so the latest version of the model is accessible

    6) the next CLI command is to compare models (the new model version and the model just created with the earlier reverse-engineering step) and create a delta model

    7) the next CLI command forward-engineers the ALTER script artifact (for applicable targets)

    8) ideally a DBA reviews the ALTER script for validity prior to applying it to the database instance

     

    The above is just an example among others to inspire the reader.  There are many permutations and variations possible based on the above scenario.

     

    Note: the responsibility for the creation of the Git repo provider triggers and the CLI commands is the responsibility of the customer

    On this page