CICD Azure DevOps
Download as PPTX, PDF0 likes191 views
This document provides an agenda and best practices for CI/CD pipelines for .NET workloads using Azure DevOps. It recommends that CI pipelines should block pull requests, run tests faster than 5 minutes, and collect metrics. It suggests repository structure, including separating code, tests, and infrastructure, and using filters to trigger specific pipelines on changes. The document also discusses gated pre-merge pipelines, build pipelines, Roslyn analyzers, SonarCloud for quality analysis, post-merge build pipelines, and release pipelines for continuous deployment.
CICD Azure DevOps
- 1. Prepared by Name Surname, Position www.intellias.com CI/CD Azure DevOps Tips and Tricks for .NET Workloads www.intellias.com Sergiy Seletsky Senior Solution Architect
- 2. Agenda 1. What is a good CI? 2. CI/CD Flows best practice 3. Build pipelines 4. Gated pipeline 5. Repo structure 6. Roslyn Analyzers 7. Sonar Cloud 8. Post-merge pipeline 9. Release pipeline
- 3. What is a good CI? 1. Should block pull requests 2. Should run faster than 5 minutes 3. Should run tests unit/integration/contract 4. Should run linters/analyzers 5. Should collect metrics quality/coverage
- 4. Build Pipelines Each microservice has at least 3 pipelines: • Gated – pre-merge blocking pipeline to verify pull-requests. • Build – just build package/container after merge and push to artifacts. • Deploy – IaaC build and verify and push to artifacts.
- 5. PULL REQUEST Gated Restore Build Test / Coverage Lint Analyse Sonar MERGED Recommended pipeline flow Build Restore Build Pack Push Publish ARTIFACTS Release Restore Run IaaC Deploy Verify
- 6. Gated Pipeline 1. Restore NuGet/Npm etc. only automated dependencies. 2. Build with Roslyn analyzers 3. Prepare Sonar environment 4. Build with Sonar analysis 5. Provision Azure Disposable Environment 6. Run tests unit/integration/cloud specific. 7. Push result of tests and coverage 8. Run Sonar Analyze 9. Publish result to Sonar Pull Request scope 10. Run extra analysis like R# or NDepend. 11. Use parallel jobs for slow parts, e.g. contract / E2E testing.
- 7. Repo Structure 1. One microservice – one repo. 2. Separate folders for src/test/IaaC/Pipelines code. 3. Use .editorconfig. 4. One Directory.Build.props per repo. 5. Readme.md should contain useful info that clearly define how to build and run this code. 6. Configure pipeline filters to be triggered on folder content change. E.g. change of IaaC only trigger Deploy Build. 7. Test folder should be excluded from advanced code analysis and analytics but still Roslyn ruleset should be followed.
- 8. Roslyn Analyzers Run checks in IDE if possible. • Should be always runed on build pipeline for double-check. • Force null free code. • No warning allowed. • Use team agreement ruleset. Code Convention as a Code. • Make sure FullDebug mode enabled for proper Sonar/Roslyn pipeline analysis. • Recommended list of analysers, adjust for your needs.
- 9. Sonar Cloud Must have on any project. • Make sure Sonar block pull request, configured in Azure DevOps Pipeline services. • Make sure valid Azure DevOps PAT set in Sonar to leave comments in pull-request code review. • Make sure no rules conflicts with Roslyn.
- 10. Post-merge build pipeline Post-merge build pipeline. • Contain only production related steps, no debug, no analysis, no tests. • Should build release mode artifacts. • Should prepare artifacts containers e.g. Docker/Lambda/Funcs. • Contracts and SDKs exported by service must be packaged in NuGet/NPM and pushed to artifacts.
- 11. Release pipelines Each microservice has own release pipeline and environments. • Triggered by pushed artifacts • Continuous Deployment for Dev/Test/Stage • Continuous Delivery for Prod
- 12. • Do not follow Blame Driven Development . • Automate DoD checks (definition of done). • Calculate roughly CBA for automation. • Force engineering culture. • Refactoring is a part of development. • Do not grow technical debt, ban it at start. • Do not create/store useless/outdated documentation. • Provide SDK/NuGet for APIs consumers. • Build once – deploy many. • Parallel pipeline and invest in fast build agent, it is cheaper than the salary of engineer and ROI is surprisingly short. Recommendations
- 13. WE INVITE TALENTED MIDDLE/SENIOR .NET ENGINEERS TO JOIN OUR TEAM The selection of original .NET vacancies, from cutting-edge e-learning platforms to innovative Automotive solutions. Pick a project of your choice, check out vacancies, and join in for the most exciting career development of your winter.
- 14. Prepared by Name Surname, Position www.intellias.com Thank you! sseletskyi@intellias.com www.intellias.com https://www.linkedin.com/in/sergeyseletsky/