The project: A .NET standalone application consisting in:
- The main application that is a Windows Service containing a web server used for the web interface. Project is 90% .NET (Framework, Standard and Core) plus a few C++ libraries
- Windows Agents that will be deployed naturally on Windows machines
- ASP.NET Core Agents that will be deployed on Linux machines
- WIX used for packing and creating the installer
We don't have a dedicated and experienced Devops team member, but we currently have in place a sort of CI/CD pipeline in VSTS. Nothing fancy, just a bunch of build definitions that run the unit tests for every commit and nightly the integration and Selenium tests split into several builds across multiple VMs (due to MSTest parallelization at the assembly level in order to decrease the run time), and another one that is manually started to create the installer.
In the near future we may need to switch to Jenkins and after spending some time messing with builds in it I grew really fond of the Pipeline plugin (especially with the Blue Ocean one). On the other side, I discovered that if you're not developing in the Java world, you're kind of screwed with even the most basic tools required for .NET like MSBuild and MSTest or VSTest lacking Pipeline support.
Only to be able to run the tests and display the results we had to do a bunch of steps, mostly consisting in batch scripts and add extra tools to be able to build, perform dotnet restore, nuget restore, run the tests, transform the .trx
file into JUnit supported ones to be able to display them.
Considering all the info above, I humbly ask the following:
- What should an "upgrade" of the existing build system look like?
- Are there any buried resources/guides/starting points in how we could make use easier of the Pipeline in the .NET world?
- Anything else that I may be missing?
We don't have a dedicated and experienced Devops team member
: DevOps is arguably a team member role, see What is the difference between Sysadmin and DevOps Engineer?