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.

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

7. Tradeoff
Cost
Scope
Time
Cost & time
Scope

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

9. Plan
Branch
Code
Merge
Build
Release
Deploy
Operate
Monitor
DEV OPS

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?!?!?!