Document toolboxDocument toolbox

Setting the Target DataStage Project Name

Introduction

The MettleCI Example CI/CD Pipelines demonstrate how the MettleCI components interact with different DataStage projects (each potentially residing in different DataStage installations) to promote the DataStage codebase through a number of virtual Environments on its way towards Production.

Each copy of a DataStage project’s codebase in each virtual Environment will reside in its own DataStage project, and each customer will have their own standards for naming those projects.

Within a given example pipeline, the name of the target project for each virtual environment is created dynamically, and the examples have been coded using a simple format of <BASE_PROJECT_NAME>_<ENVIRONMENT_ID>. The base DataStage project name is defined once, globally.

If that format does not suit, it can easily be changed. Different environments may use any target project name or format you wish.

Jenkins

Inside each stage block defined inside the Jenkinsfile, there is an environment block where environment variables are set for within that stage. This is where we set the code for the current environment, and also set the name of the target project.

stage('Deploy - CI') { agent { label 'mettleci && datastage11.7' } environment { ENVID = "ci" // Set the name of the DataStage target project for this environment DATASTAGE_PROJECT = "${env.IIS_BASE_PROJECT_NAME}_${env.ENVID}" } ... }

Azure DevOps

Inside each stage block within the Azure pipeline YAML configuration file, the variables block sets variables for use within the stage. In this example, we nominate the Variable Group to use, then define the Environment ID and name of the target DataStage project.

- stage: Deploy_CI variables: - group: demo117_NONPROD - name: EnvID value: "ci" - name: Datastage_Project value: ${{ variables.BaseIISProjectName }}_${{ variables.EnvID }} ...

GitLab

Inside the GitLab pipeline YAML configuration file, each job refers to the stage it's a part of and the agent tags it uses, then sets the environment (which allows the agent to choose the correct environment variables from the GitLab project configuration when creating the agent processes to run the pipeline).

Inside the variables block, we create the DataStage project name using the environment variables that were chosen.

deploy_ci: stage: deploy_ci tags: - mettleci - datastage11.7 environment: name: CI variables: # Set the name of the DataStage target project for this environment DATASTAGE_PROJECT: '${BaseIISProjectName}_${ENVID}' ...

GitHub

GitHub is slightly more complicated when compared to the other platforms mentioned. Due to its need to define variables through stages and then use those stages as downstream requirements in order to access their outputs, most variables need to be imported through dependencies.

When calling templated steps, GitHub does not contain an env block where you would normally set the DataStage project name. Instead, it uses a template, with arguments that are passed in. So in this case the DataStage project name is created as a parameter passed into the template.

 

© 2015-2024 Data Migrators Pty Ltd.