What you guys think about my CI set up?

I have 3 branches:
-master: production
-edge: one step of commit before production, has a tested code
-staging: where new code is added

My problem is that I have to first deploy and then after test it in my staging server.

Captura de Tela 2018-10-30 às 22.59.53.png

I am not sure what you are asking to us.

I just assume that you want to know how to execute Build, Test, Deliver in Jenkins. I think it is just a typical usecase of Jenkins.

Have you read the official Jenkins Tutorial documents published at https://jenkins.io/doc/tutorials/ ? For example, in the documented titled “Build a Java app with Maven” (https://jenkins.io/doc/tutorials/build-a-java-app-with-maven/), you can find an sample jenkinsfile as follows:

pipeline {    agent {        docker {            image 'maven:3-alpine'            args '-v /root/.m2:/root/.m2'        }    }    stages {        stage('Build') {            steps {                sh 'mvn -B -DskipTests clean package'            }        }        stage('Test') {            steps {                sh 'mvn test'            }            post {                always {                    junit 'target/surefire-reports/*.xml'                }            }        }        stage('Deliver') {             steps {                sh './jenkins/scripts/deliver.sh'             }        }    }}

This jenkinsfile implements a pipeline of Build > Test > Deliver. This is what you want to achieve, isn’t?

Of course in the stage(“Test”), you would execute “katalon” rather than “mvn test”.

I would recommend to you to go through the tutorial or any other hands-on type of readings on Jenkins.

Please be advised that Katalon Forum would not be appropriate place to ask questions about Jenkins. You should find some other appropriate web resources.

In your diagram, you seem to have 3 patterns of stage sequence in mind:

  1. Build > Deploy > Test — for the staging branch
  2. Build > Test > Deploy — for the edge branch
  3. Build > Deploy — for the for the master branch

I do not see why you want those variations. I think only one sequence : Build > Test > Deploy is sufficient for all of Git branches.

Principle is simple : when “Test” fails, you should skip “Deploy” always.


  1. Build > Deploy > Test for the staging branch

Why do you think this sequence is necessary? I do not see what you mean by “Deploy” and “Test” here. Possibly you need to clarify what you do in the “Test” stage and what you do in the “Deploy” stage.

In a simple Jenkins scenario for me, the “Test” stage for a server-side Java Web Application would include the following:

  1. setup a test fixture (test data) and a DB instance on the same machine where Jenkins runs
  2. startup a web application server (e.g. Tomcat) on the same machine where Jenkins runs
  3. deploy the app jar into the container
  4. http://localhost:8080/yourapp/ should become accessible
  5. execute Katalon test against that URL
  6. shutdown the web application server and DB instance
  7. report the exit status of the Katalon test to Jenkins

You can host the AUT on the localhost of Jenkins box. You do not necessarily need to do full-deploy of AUT on other machine.

The shell script for “Test” stage would be fairly rich one. It would not be one-line script which just calls the katalon binary.

Hello kazurayam,

thanks a lot for your attention and your response.

Actually no, it is not about Jenkins flow.

It’s about about my overall app testing rationality.

Something I did not mention is that the katalon test is performed in a server running my app and not in a docker container. So, if I want to test a certain commit, let’s call it A, I need to deploy this code A to staging server and then after run the tests on top of it.

In this case if I run the tests before I deploy, I would be running the tests with the previous pushed code, which is one or more commits earlier then the current I want to test it (A)

So, based on your last example would it be easier if I have a specific VM just to run katalon and other VM to run my app in testing.
In case we separate the flow in two VMs, do you agree that in this case the flow would change to Build > Deploy > Test, for the staging branch ?

And since we have fully tested the edge branch when we push it to master, why do we need to test it again ?

Actually no, it is not about Jenkins flow.
It’s about about my overall app testing rationality.

I am afraid it is too abstract to discuss about in a web-forum format. I have no more words to speak.

Wittgenstein wrote “Whereof one cannot speak, thereof one must be silent”. :wink:

well, ok…thanks for the effort anyway