Implementation of CI/CD in .NET application Using Shell Executor on GitLab

Continuous Integration and Continuous Deployment (CI/CD) have revolutionized software development, allowing teams to automate build, test, and deployment processes for rapid and reliable software delivery. In the .NET ecosystem, implementing CI/CD pipelines is important for maintaining code quality, improving collaboration, and accelerating time-to-market.

GitLab, a popular DevOps platform, offers powerful CI/CD capabilities, including the versatile Shell Executor, which enables seamless automation of tasks within CI/CD pipelines. In this article, we’ll explore how to implement CI/CD for a .NET application using GitLab’s Shell Executor, empowering you to streamline your development workflow and enhance productivity.

Understanding CI/CD with GitLab:

Before diving into implementation details, let’s briefly review the concepts of CI/CD and how GitLab facilitates their implementation:

• Continuous Integration (CI): CI involves automatically building and testing code changes whenever they are pushed to a shared repository.
• Continuous Deployment (CD): CD extends CI by automating the deployment of code changes to production or other target environments.
• GitLab Shell Executor: The Shell Executor is one of GitLab’s available executors for running CI/CD jobs. It executes commands directly on the CI runner’s host machine, providing flexibility and control over the execution environment.

Requirements

 Path Configuration

 
GitLab Runner Set Up

Follow the below steps to download and configure the GitLab Runner.

1. Download GitLab Runner for Windows

2. After downloading successfully, save it in your directory (For ex: C:\Tools\GitLab-Runner), and rename it with the following command

gitlab-runner.exe

3. Open Command Prompt on Admin Mode, go to GitLab-Runner directory and check the status of it using 

gitlab-runner status

4. If it is already running, stop it before registering a repository with GitLab Runner 

gitlab-runner.exe stop

5. Once GitLab Runner has successfully stopped then use the following command for the repository registration

gitlab-runner.exe register

6. When you do repository registration with GitLab Runner, the below questions have to answer.

• Enter your GitLab instance URL: It can be different with each organization and format will be like http://gitlab.example.com                    
• Path: Go to GitLab Account → Select repository which you want to register with runner → Settings → CI/CD → Expand Runner
• Enter the gitlab-ci token for this runner: It will be a unique token of each project which will need while registration and it can be found    
• Path: Go to GitLab Account → Select repository which you want to register with runner → Settings → CI/CD → Expand Runner
• Enter the gitlab-ci description for this runner: Put Runner name(any name), which will help you to remember that which runner’ is running
• Enter the gitlab-ci tags for this runner: It is an optional, if you want to start GitLab runner when specific tag is available in yml file.
• Enter the executor: There will be list of several executors, and type shell(as GitLab Runner will run our system)

7. After successful registration, start the GitLab Runner 

gitlab-runner start

8. To verify that GitLab Runner has registered the respective repository and the runner has been started. Go to GitLab Account → Select repository which you want to register with runner → Settings → CI/CD → Expand Runner, There will be a green color circle will be available, and displaying message will be Runners activated for this project.  

Note: If the circle is gray, it means the runner has not started and starts again.

 Windows GitLab Runner Command

.gitlab-ci.yml:  This is a format of .gitlab-ci.yml and changes it based on requirements 

variables:
 NUGET_PATH: 'C:\Tools\Nuget\nuget.exe'
 MSBUILD_PATH: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe'
 MSTEST_PATH: 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\mstest.exe'
 TEST_FOLDER: '.\test\bin\Release'
 
stages:
 - build
 - test
 - deploy
 
before_script:  
     - '& "$env:NUGET_PATH" restore sourcecode\project.sln'  # sourcecode\project.sln-This path includes project solution where is available and restoring
     - '& "$env:NUGET_PATH" restore test\test.sln'     # This path includes test solution where is available.  and restoring      
         
build_job:
 stage: build
 only:
   - developer #this branch will run on GitLab Runner and can change it.  
 script:  
    - '& "$env:MSBUILD_PATH" sourcecode\project.sln /p:DeployOnBuild=true /p:Configuration=Release  /p:Platform="Any CPU" /P:PublishProfile=FolderProfile.pubxml'  
    - '& "$env:MSBUILD_PATH" test\test.sln /p:DeployOnBuild=true /p:Configuration=Release /p:Platform="Any CPU" /P:PublishProfile=FolderProfile.pubxml'  
 
 artifacts:
   expire_in: 365 days  #artifcats will be stored only 365 days after this it will expire  
   paths:
     - '.\sourcecode\project.sln\bin\Release\Publish\'
     - '.\sourcecode\project.sln\bin\Publish\'
     - '$env:TEST_FOLDER'
     - '.\$env:MSTEST_PATH\*.*'

test_job:
 stage: test
 only:
   - developer #this branch will run on GitLab Runner and can change it.  
 script:
   - .\test\test.bat  #This is bat file, if the test are written in script format  
   
 dependencies:
   - build_job

deploy_job:
 stage: deploy
 only:
   - developer #this branch will run on GitLab Runner and can change it.  
 script:
    - 'xcopy /y /s ".\sourcecode\project.sln\bin\Release\Publish\*.*" "C:\solutionDir"'  #Path where you want to store the solution  
 
     
 dependencies:    #after successfully build, only test stage will run  
   - build_job
   - test_job

Code Commit: After successful configuration, do commit and see the job status on GitLab. Go to Project repository → Select CI/CD menu 

amiransarimy

Follow

Improve

Article Tags :

• C#
• Computer Subject
• GBlog
• Git
• Web Technologies
• Dot-NET

+2 More