Jakiś czas temu pisałam na temat innych serwisów Azure DevOps – Repos i Pipelines. Dzisiaj czas na Boards i konkretny problem ustawienia procesu dla naszego projektu.

Test wydajności .NET na Linux (Ubuntu 20.04) i Windows 10. Użyte środowiska uruchomieniowe .NET: .NET Core 3.1, .NET 5.0 i Mono

When you create a build pipeline you must sometime decide at runtime whether run some code or not. One of the options for this is output variables. It enables you to set a variable in one job and use this variable in the next job.

I need to migrate a lot of repositories from one Azure DevOps to another. Migration! Don't ask why, please. Let's assume it was much more simple than other options.

Gdy tworzymy jakieś API dobrze jest sprawdzić, czy ono działa. Po każdej zmianie albo dodaniu nowego punktu wejścia (endpoint) powinniśmy przetestować, czy wszystko jest ok. Możemy to zrobić uruchamiając aplikację i ręcznie wszystko sprawdzając, jednakże na dłuższą metę jest to bardzo czasochłonne. Dlatego warto utworzyć osobny projekt, w którym stworzymy testy sprawdzające czy nasze API działa poprawnie. W kilku punktach postaram się opisać jak u mnie z reguły wygląda taki projekt z testami API.

EventPipeProfiler is a new cross-platform profiler that I’ve implemented in the BenchmarkDotNet library. It allows profile .NET code on every platform - Windows, Linux, macOS. Collected data are exported to trace files (.speedscope.json and .nettrace) which can be analyzed using SpeedScope, PerfView, and Visual Studio Profiler. This new profiler will be available from the 0.12.1 version.

Last time we created a gated check-in build for .NET Core app. It works very well, but we did there one thing which is in general a bad practice in our proficiency. We duplicated build steps for building and testing .NET Core app. We can do better than that, we can use templates. Following the documentation: Templates let you define reusable content, logic, and parameters. Templates function in two ways. You can insert reusable content with a template or you can use a template to control what is allowed...

Standard CI build checks integrity of committed code after merge. This approach can lead to a state when code is not deployable due to failing tests or even failing compilation. Gated check-in helps to protect the integrity by verifying state before the merge. In that way, you can protect your master branch and avoid build breaks. In that way, you can ensure that your master branch is always deployable (what is crucial in GitHub flow) and you will not interrupt your colleagues with your obvious mistakes....

You may not know this, but there is a part of Allegro codebase which we started developing in C# due to some special requirements. This implies new programming opportunities and challenges — one of these is creating a completely new .NET Core starter project. Let’s explore one potential solution: dotnet new templates.

Azure DevOps can do many marvelous things. It gives you process transparency and automation and so much more with logging and simply more control of the CI/CD processes. Here is a story on how to manage and automatically control you deployment process using enterprise tools.