Svetlin Krastanov, DevOps Leed and Senior .NET Developer at VSG
Having entered the world of DevOps and automation in the first part, now it is time to continue our journey and go even deeper into the mechanisms of automation. We focus on adding a version of the projects, working with deployment environments and secret variables, using Docker and GitHub Actions, as well as automatically generating a file with changes and releases.
Link to the first part: https://dev.bg/digest/vsg-bulgaria-devops-automation-dc03/
1. Add a version of the projects:
To maintain consistency and organization in our projects, it is extremely important to have version management. The first step is creating a VERSION file containing the current version of our project. When built, this file allows us to change the version of all .NET projects in the process. This effectively facilitates the tracking and management of different versions.
To add a version of all projects in our repositories, we can create a single VERSION file in the root directory in which we will add a sample version as 1.0.42 (example)
Then, in our processes in the ".GitHub/workflows" folder, we edit the build files by adding the following code: (example).
1. - name: Set VERSION variable
2. shell: bash
3. run: |
4. VER=$(cat VERSION)
5. VER_LONG="$VER.${{github.run_number}}"
6. echo "VERSION_CI=$VER_LONG" >> $GITHUB_ENV
7. - name: .NET project version updater
8. uses: vers-one/dotnet-project-version-updater@v1.2
9. with:
10. # Projects file path
11. file: "src/**/**/*.csproj"
12. # New version
13. version: "${{ env. VERSION_CI }}" One of the best practices when we already have a version is to easily add a tester to reach the version. For RIA projects, you can make a request to return it, and in front end or mobile projects, it can be added to the corner of the application or a special page "about the application".
2. Deployment media and secret variables:
The next step is to use GitHub environments and environment secrets to manage deployment environments and secret variables. This allows us to isolate different development, testing and production environments and maintain the safety of our secret variables without leakage.
First, we go into GitHub, settings of the repositories, and then it is the middle. We add a unique environment named "Azure" and in it we can add a new secret variable with an example name "BlazorApp1_DeployToken".
Then we go to the file that manages the deployment process in "Azure" and add the environment and the secret variable.
In this way, we can create different environments with different secret or simple variables that will be visible only to automated processes and only to project administrators.
3. Docker and distribution:
Excellent! We already have versions, we have environments with secret variables, it is time to take on Docker, a powerful platform that allows creating, distributing, and executing applications in a containerized environment.
Using Docker in the development process brings numerous advantages. It allows applications to be packaged with all their dependencies in a standard format that can be distributed and used over any platform and environment without the need to make special settings.
The first step, as always, is to add a new file to ".GitHub/workflows" with the example name "blazorapp1-docker-github.yml" (examplehttps://github.com/Magik3a/dev.bg/blob/main/.github/workflows/blazorapp1-docker-github.yml)
The last step is to add a new "Docker file" to the folder "src /BlazorApp1" (example).
Once you have added everything, you will see your docker image in the repositories and any tester or programmer can execute the command and run the application on their local computer without the need for absolutely nothing but Docker!
1. docker pull ghcr.io/magik3a/dev.bg.blazorapp1:latest
2. docker run ghcr.io/magik3a/dev.bg.blazorapp1:latest
Once we download and run the docker, we can open the https://localhost:7018 and see that everything is running locally on our computer.
Link to docker image in the example here.
The use of Docker ensures consistency between development, testing and production environments. This means that if the application runs on your local machine in a Docker container, it is highly likely to work the same way in the production environment.
4. Automatic releases and change file generation (Changelog):
Creating automatic releases and documenting changes made to the project are critical aspects of the software development process. In this context, GitHub Actions provides effective tools that can facilitate and automate these tasks.
First, we will create in "GitHub" a new task with an example title: Create release drafter (examplehttps://github.com/Magik3a/dev.bg/issues/5).
Then in the folder ".GitHub" we add a new file named "release-drafter.yml" , which we will use to template the description in our relay (example).
We last add a new file to '.GitHub/workflows' with example name 'release-dist.yml' (example).
When we decide that we are ready for the release and our code is good enough, we go to the actions in "GitHub" and manually run "Release Distribution Packages" (we can do it automatically when a new code enters the main branch).
And our final release looks like this:
In general, automatic release creation and change file generation are an important part of DevOps practices and are an essential part of an efficient and fast software delivery process.
5. Excellent job!
By mastering the practices described in this article, you have already made quick progress in creating an automated DevOps environment. Using Docker, GitHub Actions, and other tools allows you to improve your software development, testing, and distribution processes.
Creating consistent, insulated, and repeatable environments with Docker is a powerful strategy to improve the quality and reliability of your projects. Automatic release creation and changelog generation improves transparency and communication within the team and when communicating with customers.
All these strategies and tools lead to the same end - achieving high efficiency, improved code quality, security, and speed of delivery.
But if there is one thing to remember, it is that DevOps is a constant process of improvement and adaptation. We must continue to look for new and improved methods of automation and optimization of our processes. No matter if you are new to DevOps or an experienced professional, there's always room for training and improvement.
In the next part of the series, we will get into a little more complex things (and unfortunately some of them paid), such as bot creation, integrations with Microsoft Teams and Skype, and distribution in Kubernetes and Chaos engineering.
Thank you for your time and for reaching the end of the article! Bravo for the work done and keep striving for efficiency and quality at every step of your DevOps process!
