In this post, we will show how to set up a sample CI/CD (continuous integration / continuous deployment) pipeline built on Jenkins for our Dataiku DSS project. It follows our blog post Continuous integration and continuous deployment (CI/CD) in Dataiku DSS that presents the concepts and some important questions in order to fully optimize CI/CD.
In order to be at ease with this article, you will need to know about DSS flows, scenarios, and automation. I strongly recommend following the Operationalization series from the Dataiku Academy. In addition, an understanding of Jenkins and the basics of Artifactory are required, plus basic Python skills, including pytest ideally.
Our CI/CD environment will be made of:
We will use the Dataiku DSS Prediction churn sample project, with a twist at the end with a Python recipe. The code itself is not really important; we need some Python code to showcase code analysis.
Note: You can find all the files used in this project attached to this article as dss_pipeline-master.zip
The first step is to create a project in Jenkins of the “Pipeline” type. Let’s call it
We will use the following parameters for this project:
The pipeline contains five stages and one post action:
The post action will be used to clean up the bundle zip file from the local jenkins workspace to save space and will also retrieve all the xUnit test reports.
As additional global notes, we are using a global variable
bundle_name so that we can pass this information from one stage to another. This variable is computed using a shell script with the date & time of the run (the script is explained after it is displayed).
You can find the groovy file of the pipeline in the zip: pipeline.groovy. In this file, you have the definition of the different stages and for each stage the details of the steps.
Let’s review those steps one by one.
This stage is used to build a proper workspace. The main tasks are to get all the CI/CD files we need from your GitHub project and build the right Python3 environment using the requirements.txt file.
Since the Dataiku DSS API python package is retrieved from a node directly, we are using the Design node URL provided as parameter for that.
This stage contains mostly Python scripts used to validate that the project respects internal rules for being production-ready. Any check can be performed at this stage, be it on the project structure, setup, or the coding parts, such as the code recipes or the project libraries.
Note that we are using pytest capability to use command-line arguments by adding a conftest.py.
This is very specific to each installation, but here are the main takeaways:
If this state is OK, we know we have a properly written project, and we can package it.
The first part of this stage is using a Python script to create a bundle of the project and download it locally on the Jenkins executor.
The second part is using a Jenkins stage to publish this bundle on our Artifactory repository
generic-local/dss_bundle/. Note that the stage will fail if no file is published (the “failNoOp: true” option) so there is no need for an extra check.
In this stage, we are deploying the bundle produced at the previous stage on our DSS PREPROD instance and then running tests.
The bundle import is done in import_bundle.py and is straightforward: import, preload, activate. In this example, we consider connection mappings are automatically done. If you need specific mappings, this requires some more work using the API (see XXX)
The following script run_test.py executes all the scenarios named TEST_XXX and fails if a result is not a success.
You can check on the blog article why we are using DSS scenarios.
This pytest configuration has an additional twist. If you have only one test running all the TEST_XXX scenarios, they will be reported to Jenkins as a single test, successful or failed.
Here, we make this nicer by dynamically creating one unit test per scenario. In the final report, we will have one report per scenario executed, making the report more meaningful. This requires some understanding of pytest parameterization. Note that you can perfectly keep one test that will run all your scenarios if you are not feeling at ease with this.
The previous stage verified that we have a valid package. It’s time to move it to production!
Again using Python with script import_bundle.py, we will upload the bundle to the production node using the same logic as in PREPROD.
The second script prod_activation.py will handle the activation and the rollback. For that, here are the main steps:
The Post Actions phase allows us to clean locally downloaded zip files and publish all test xUnit reports in Jenkins to have a nice test report. Those reports were produced all along the pipeline by pytest and are here aggregated into a single view to have something like:
Now we have seen a step-by-step demonstration of how to build a solid CI/CD pipeline with Jenkins. If you want to use this and adapt it to your setup, here is a checklist of what you need to do:
And then hit ‘Build with parameters’.
You can of course improve this startup kit, and here are some ideas:
And of course, add as many test scenarios as possible that will ensure a reliable continuous deployment.