Writing mostly about the journey of a Chapter Lead: leading a team of 9 development engineers in 5 squads for 5yrs+
Before this, I was myself an individual contributor, skilled in Python and Frontend.
CI/CD should be a hard requirement on any project that involves more than one contributor; although I would practice it even on individual / side projects. It's hygienical.
Steps should be automatic, as much as possible (sample steps: build, test, apply db changes, asset deployment, cache invalidations etc.)
The complexity and number of the stages and checks depend on your functional and non-functional requirements, and how much they matter to you (read: to the stakeholders): what's the minimum test coverage you want, do you care about linting, how about sonar/code quality? Four eyes principle, using a protected git branch - any change management steps? Accessibility tests, load tests? Pre-production environment for smoke test? Canary deploy on 5-10% of traffic before moving forward?
The list can go on and on - the sky is the limit. But the principles remain:
as much as possible, everything should be versioned and automatic (automate anything, anything replay-able)
make it run fast, keep the feedback loop short
every change should trigger the feedback process
broken pipeline = every body should focus on making it work again (although i've heard there are some alternatives on this).
include the checks / quality gates that matter to your stakeholders
Imho, CI/CD is a craft in itself. I read the first parts of Continuous Delivery by Jez Humble and David Farly, as advised by my lead, and I can't not recommend it further. It's great stuff, regardless of your career path in software products, or engineering.
In my org., i've studied the frontend build & deploy process, and we do use all the harness for building (npm, webpack), running tests (unit), then also vulnerability scan, dependencies versions check (again, for security checks). They're all triggered when merging to designated protected branches. A subset is run when opening the PR (so a merge does not break the integration pipeline).
All pipeline configurations are stored in versioned .yml-s, inside the repo of the deliverable; since we use Azure DevOps for the whole ecosystem.
Mkay, maybe I should keep this short. Wish you all of the peaceful, in-control moments the CI/CD process brings into teams:)!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
CI/CD should be a hard requirement on any project that involves more than one contributor; although I would practice it even on individual / side projects. It's hygienical.
Steps should be automatic, as much as possible (sample steps: build, test, apply db changes, asset deployment, cache invalidations etc.)
The complexity and number of the stages and checks depend on your functional and non-functional requirements, and how much they matter to you (read: to the stakeholders): what's the minimum test coverage you want, do you care about linting, how about sonar/code quality? Four eyes principle, using a protected git branch - any change management steps? Accessibility tests, load tests? Pre-production environment for smoke test? Canary deploy on 5-10% of traffic before moving forward?
The list can go on and on - the sky is the limit. But the principles remain:
Imho, CI/CD is a craft in itself. I read the first parts of Continuous Delivery by Jez Humble and David Farly, as advised by my lead, and I can't not recommend it further. It's great stuff, regardless of your career path in software products, or engineering.
In my org., i've studied the frontend build & deploy process, and we do use all the harness for building (npm, webpack), running tests (unit), then also vulnerability scan, dependencies versions check (again, for security checks). They're all triggered when merging to designated protected branches. A subset is run when opening the PR (so a merge does not break the integration pipeline).
All pipeline configurations are stored in versioned .yml-s, inside the repo of the deliverable; since we use Azure DevOps for the whole ecosystem.
Mkay, maybe I should keep this short. Wish you all of the peaceful, in-control moments the CI/CD process brings into teams:)!