The Codeshuttle is a CI/CD pipeline designed to reduce the amount of effort and knowledge a development team is required to have in order to fully utilize a build, test, and deploy pipeline. In short, a shortcut for developers to use pipeline.
A - Introduction
This article will describe the process of build and deployment from DEV, TEST, UAT, to PROD servers, the combination workflow of Repositoy (GitHub) and Automation (Jenkins). They are all in the Code Shuttle environment. The content of this article will include:
- A - Introduction
- B - Stage 0 --- Setup Environment
- C - Stage 1 --- Working on Feature Branch
- D - Stage 2 --- Working on Deployment Branch
- E - Stage 3 --- Deploy to PROD and Merge Code to Main
- F - Stage 3 Modified --- Automation
B - Stage 0 --- Setup Environment
We can start either from repos server or from client side. Now we start from Client side, create two Branches from main as
- George-HCOA-28942-2_uspMailICIPStage.sql --- Feature Branch
- dev-HCOA-28942-2_uspMailICIPStage.sql --- Deployment Branch
where, George- branch is a working branch or Feature Branch in the development process, agianst that we will make any modifications for our logic changes; while dev- branch is a deployment branch that will be merged from Feature Branch after the development and deployed to servers, such as DEV, QA, TEST, UAT, PROD.
![]()
Push both Feature branch and deployment branch to GitHub Server, we have
![]()
C - Stage 1 --- Working on Feature Branch
First we will work on Feature Branch in Client side, that includes:
- Make modifications by business requriements;
- Push to Server (Remote)
- Merge into Deployment Branch
After modifications for Feature Branch, push to server from Visual Studio:
![]()
At this point, we have finished the first Stage. The workflow below includes both Stage 0, setup the Environment and Stage 1, working on Feature Branch:
![]()
In the workflow, the process is from Server to create the Feature Branch and Deployment Branch and pulled into Client, while we Creating the two branches from Client side and pushed to server, They are the same.
D - Stage 2 --- Working on Deployment Branch
Now we will work on the Deployment Branch from server side, that includes:
- Merge the Feature Branch into Deployment Branch
- Build the Branch in pipeline
- Deploy the Branch to DEV, TEST, UAT, and PROD Server
Create a Pull Request (after push, we can do it from server, too):
![]()
From server, GitHub, Open a Pull Request against the dev- or deployment Branch:
![]()
Create the Pull Request from Server:
![]()
Merge the Feature Branch into the Deployment Branch:
![]()
The merge will auto trigger the Build process in the pipeline:
![]()
such as
![]()
The build is completed, and at the same process, the build has been deployed to DEV server, which we do not need to do it independently any more:
![]()
Setup Deployment in TEST server. Because the deployment to DEV has been done in the build process, we can directly deploy the branch to TEST server:
![]()
Click Build to start:
![]()
Completed. Setup the deployment to UAT then:
![]()
Client Build button to complete the deployment to UAT:
![]()
At this point, we have completed the process in the workflow below:
![]()
E - Stage 3 --- Deploy to PROD and Merge Code to Main
Because this is a deployment process, it could be finished in minutes or an hour, and it could be lasting several days. During this period, it could be that somebody else merge content into main branch, which could be conflict with what we are working on. So, we need to check with the main branch to see if mergable. Otherwise we have to handle the conflict first. While if conflict, we cannot just modify the code, because the code is in a deployment process, if the code was changed, then the previous build would be invalid. So, if there is any conflict with main branch, we have to start the process from the very beginning, as it is shown in the workflow below:
![]()
After the checking with main branch, only without conflict, we can proceed forward to the next step:
Setup deployment to PROD:
![]()
Click the Build Button to complete the deployment to PROD:
![]()
Finally, merge back to main to complete the whole process.
F - Stage 3 Modified --- Automation
In the process above, the Stage 3, we have to manually compare the Deployment Branch to Main Branch, say, in client side (say, in Visual Studio). We can make the process automatically to merge the Deployment Branch directly to Main Branch, without manually comparison, if it is mergable, then go proceed. otherwise, go back to the beginning to handle the conflicts. The workflow is like this:
![]()
For this process, we should handle some common files, such as deploylist.yml file, to make them ignored in the process, because they must be different in the different users, but they do not affect the process, we can just keep them as them.
In this auto process, in the Stage 1, we do not need to pull the Deployment Branch to local. Because we do not need to compare it to Main in local:
![]()