<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>CI/CD on Daniel Genezini</title><link>https://genezini.com/tags/ci-cd/</link><description>Recent content in CI/CD on Daniel Genezini</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>2022 Daniel Genezini All rights reserved</copyright><lastBuildDate>Tue, 29 Nov 2022 08:20:00 -0300</lastBuildDate><atom:link href="https://genezini.com/tags/ci-cd/index.xml" rel="self" type="application/rss+xml"/><item><title>Keep your diagrams updated with continuous delivery</title><link>https://genezini.com/blog/p/keep-your-diagrams-updated-with-continuous-delivery/</link><pubDate>Tue, 29 Nov 2022 08:20:00 -0300</pubDate><guid>https://genezini.com/blog/p/keep-your-diagrams-updated-with-continuous-delivery/</guid><description>&lt;img src="https://genezini.com/blog/p/keep-your-diagrams-updated-with-continuous-delivery/cover.jpg" alt="Featured image of post Keep your diagrams updated with continuous delivery" /> Changing software diagrams is hard. The simple act of adding a new box may require us to drag all the existing boxes and reorganize the diagram. This is one of the main reasons to why software diagrams are constantly left deprecated after the first stages of the development process.
In this post I'll show how defining diagrams as code can help in designing and updating software diagrams, and how to automate the process of updating the documentation with those diagrams.</description></item><item><title>Analyzing and enforcing .NET code coverage with coverlet</title><link>https://genezini.com/blog/p/analyzing-and-enforcing-.net-code-coverage-with-coverlet/</link><pubDate>Thu, 03 Nov 2022 08:10:00 -0300</pubDate><guid>https://genezini.com/blog/p/analyzing-and-enforcing-.net-code-coverage-with-coverlet/</guid><description>&lt;img src="https://genezini.com/blog/p/analyzing-and-enforcing-.net-code-coverage-with-coverlet/cover.png" alt="Featured image of post Analyzing and enforcing .NET code coverage with coverlet" /> Automated software tests are a requirement for ensuring we are delivering a product with quality to our users. It helps in finding bugs and requirements not fulfilled at development time, but also decreases the cost of maintenance by making the future changes to our code safer. Besides, the act of writing testable code alone increases the quality of the code we are writing because testable code has to be decoupled.
In this last post of this series, I'll show how to analyze and enforce a minimum code coverage in our applications, and how to use integration tests to increase our testing surface.</description></item><item><title>Enforcing .NET code style rules at compile time</title><link>https://genezini.com/blog/p/enforcing-.net-code-style-rules-at-compile-time/</link><pubDate>Tue, 25 Oct 2022 08:00:00 -0300</pubDate><guid>https://genezini.com/blog/p/enforcing-.net-code-style-rules-at-compile-time/</guid><description>&lt;img src="https://genezini.com/blog/p/enforcing-.net-code-style-rules-at-compile-time/cover.png" alt="Featured image of post Enforcing .NET code style rules at compile time" /> Static code analysis is a great tool for spotting some kinds of error in your code, for example, not disposing of objects that implement IDisposable. Also, it helps to enforce and validate if the code written is following a defined standard, for example, using PascalCase for class names and camelCase for parameter names.
In this post I'll show how to use Roslyn Analyzers with C# to enforce some standards of code quality and code style on your code, throwing errors at compile time if any rules are not being respected and not allowing the code to be pushed to protected branches of the repository.</description></item></channel></rss>