CI CD OPS WHATHAVEYOU
Download as PPTX, PDF0 likes13 views
CI/CD aims to allow teams to deliver software quickly and reliably by automating the build, test and deployment processes. This helps reduce bugs, ensures all code changes are validated, and provides live documentation of how to build and release software. The document outlines best practices for CI/CD like naming conventions, email notifications on failures, and provisioning testing environments to validate code changes before production deployment. It also notes potential problems like dependencies on specific operating systems and challenges with infrastructure provisioning.
CI CD OPS WHATHAVEYOU
- 1. CI/CD/DEVOPS WHY A guide towards a CI/CD best practice
- 2. Motivation Allow us to deliver anytime anywhere (top priority) Decrease feedback loop Tell the dev that he broke something Introduce a relyable way to “smoke out” the project Prevent “Works on my machine” lazy practice Provides a live documentation of “how to build” Validate against “latest master” status after each push
- 3. Allow us to deliver anytime anywhere End user wants everything delivered FAST Delivering requires thorough documentation •(which is a thing that we are BAD at) •(and automation solves this by providing a ”working example”) We need to “document” how to release The act of delivery prevents code from being developed on PRODUCTION machines The granule of release is the granule of reuse
- 4. CI outline Predefinition • Install prerequisits like JAVA, .NET, MSBUILD, NODE+globally used package • Clear up machine, vms or docker images Build • Lint / static code analysis • check • Build/ compile /transpile /crap-pile • Package Test • Run unit tests • Run integration tests • Run e2e (smoke) tests • Run performance suite Deploy • DEV – any commit • QA – by tag only!!! • PROD – by manual approval!
- 5. Provisioning CI • GITLAB that speaks your OS language • Test dependencies • DB • external servicees (SIP server, map server etc) • external devices • simulators CD • Same as CI • QA_TEST machine for NG QA • STAGE machine for customer • PROD machine for customer
- 6. Provisioning JENKINS_SERVER • Jenkins • MySQL • SQL express QA TEST (1 machine to rule them all?) STAGE – pre-prod?? PROD – 1 machine per product per customer
- 8. Project VS Product • Features • Cost • Time • Quality • Features • Cost • Time • Quality Plan •Charter •Lessons learned •Define schedule & deliverables Execution and control •Iterate •Monitor and react •Measure progress •Log issues and risk •Log changes in requirements/baseline •Change log •Keep in touch with customer Closing •Acceptance •Performance measure •Final status report •Lessons learned Plan • Product backlog grooming • Spring planning • Sprint backlog Sprint execution • Daily progress • Daily standup • IGNORE THE CUSTOMER Potentially shippable increment Sprint reciew • Acceptance • Performancemeasure • Final status report Sprint retrospective • Lessons learned • Fixed • Variable
- 10. DCM checkout •Master branch Install dependencies •Vs local repo or static Pre-build •Lint •Check Build •Compile/transpile Test Package •Configuration management Deploy DEV Deploy TEST ENV for QA Approve Deploy PROD Code flow and CI 10 31.07.2023
- 11. https://docs.gitlab.com/ee/ci/pipelines/job_a rtifacts.html Steps etc TODO gitlab.yaml 11 31.07.2023
- 12. Project lifecycle Agile Focuses on Process Highlights Change While accelerating Delivery CI/CD Focuses on Software defined life cycles Highlights Tools That emphasize Automation DevOPS Focuses on Culture Highlighting Roles That emphasize responsiveness
- 13. CD end-to-end PREDERFINES VCS get BUILD TEST Deploy TEST_QA Deploy STAGE Deploy PROD PREDERFINES VCS get BUILD TEST Deploy TEST_QA Deploy STAGE Deploy PROD PREDERFINES VCS get BUILD TEST Deploy TEST_QA Deploy STAGE Deploy PROD PREDERFINES VCS get BUILD TEST Deploy TEST_QA Deploy STAGE Deploy PROD
- 14. Best practices Every JOB name should be named by it’s JIRA TAG Every CI job should be prefixed by the CI prefix Every CI build version should be the SVN version Every CD job should be prefixed by the CD prefix Every failure should send an email to project owner AND departmant manager. There should be a NG QA test machine dedicated for all projects / per project (if not applicable) All artifacts will be sent to SYSTEMS FTP
- 15. Problems • Main controller is a windows machine – We’ll handle linux/debian/kolibrios when a problem is met. • Provisioning is a pain! – ??? • Anywhere?!?!?!