jerryschen31 / learn

Scratch repo used for learning stuff
GNU General Public License v3.0
0 stars 0 forks source link

2023-03-12 feature flags and trunk-based CI/CD development #22

Open jerryschen31 opened 1 year ago

jerryschen31 commented 1 year ago

https://github.com/laravel/pennant

Principles https://www.atlassian.com/continuous-delivery/principles/feature-flags

Cleaning up https://www.optimizely.com/insights/blog/manage-outdated-feature-flags/

Trunk-based CI/CD development https://trunkbaseddevelopment.com/

jerryschen31 commented 1 year ago

Trunk-based development (Google doc) https://cloud.google.com/architecture/devops/devops-tech-trunk-based-development#:~:text=Trunk%2Dbased%20development%20is%20a,the%20system%20is%20always%20working.

There are two main patterns for developer teams to work together using version control. One is to use feature branches, where either a developer or a group of developers create a branch usually from trunk (also known as main or mainline) and then work in isolation on that branch until the feature they are building is complete. When the team considers the feature ready to go, they merge the feature branch back to trunk.

The second pattern is known as trunk-based development, where each developer divides their own work into small batches and merges that work into trunk at least once (and potentially several times) a day. The key difference between these approaches is scope. Feature branches typically involve multiple developers and take days or even weeks of work. In contrast, branches in trunk-based development typically last no more than a few hours, with many developers merging their individual changes into trunk frequently.

jerryschen31 commented 1 year ago

Breaking up code work into small batches (one commit per day!) https://cloud.google.com/architecture/devops/devops-process-working-in-small-batches

jerryschen31 commented 1 year ago

I think with trunk-based approach, need to have all automated unit and functional tests comprehensive and in place BEFOREHAND, so that any merge requests to trunk fire off all the tests before merging