This article can be used as a quick reference for setting up code release pipeline for .net based projects. Gitlab pipelines is used here , but the solution can be generalised for other CI/CD automation tools available in market
Gitlab runner is a build agent where all the build operations happen . If you are using gitlab.com for your git repositories , then configuring a runner in your VPC is a valid candidate for security sustenance
NOTE: It is a good practice to register a common group runner for all the projects in a group.
7. Register the runner with gitlab.com
Verify Runner status on gitlab.com ( Group > Settings > CICD > Runners )
8. Install Git on this server from here.
9. Download build tools from Visual Studio Microsoft
NOTE: Installing build tools requires reboot
NOTE: Make sure to restart gitlab runner service after all the utilities are added to system path. Else changes will not be picked up by the service
Application servers also need to be configured to support remote deployment via msdeploy command . This link can be referenced as an in-depth guide .
GItlab pipelines is now ready to use registered runner for build and deployment actions.
Gitlab CICD environment variables should be used to securely inject sensitive information in pipeline.
This is a sample yaml file which can be placed in project root directory
/Y can be replaced while manually testing deploy command. It runs the deploy command with -whatif flag which executed the deploy command in dry run mode/M represents the machine address where site has to be deployed .
https://172.31.1.224/MSDeployAgentService : Address when when remote agent is used
https://172.31.1.224:8172/msdeploy.axd : Address when Web deploy handler is used
NOTE: notice the username and password injection in deploy script . both are CICD environment variables added in project settings and password is masked to avoid exposing value in build logs
GitLab CI/CD is a continuous integration and deployment tool integrated with GitLab, enabling automated workflows for building, testing, and deploying code changes.
Define a .gitlab-ci.yml file in your .NET project repository, specifying stages like build, test, and deploy. Each stage will contain scripts to run .NET commands like dotnet build and dotnet test.
In the .gitlab-ci.yml file, create a build job that uses a .NET Docker image. Run the dotnet build command to compile the project.
Use Git tags, commit messages, or a versioning tool like GitVersion in the pipeline to dynamically update the version number for each release.
Define a test job in the pipeline file that uses dotnet test to run unit tests. This can be included as a separate stage before deployment to ensure quality.
Use dotnet restore in the pipeline to download dependencies from NuGet. You can configure NuGet sources in a NuGet.config file if needed.
In the build stage, use dotnet publish to package the application, specifying an output directory. This published folder can then be stored as a pipeline artifact for deployment.
Use SSH or GitLab’s CI/CD environment variables to securely deploy the published artifacts to the target server, or use deployment tools like Octopus Deploy.
GitLab CI/CD provides a secure environment for storing sensitive information. You can add secrets like database credentials as CI/CD variables, accessible during pipeline runs.
In the .gitlab-ci.yml file, set a deploy job that triggers on specific branches, tags, or GitLab releases, so the project is automatically built and deployed when changes are pushed to these branches.