You currently seem to have a flow that's similar to the flow used by the git project or a slightly modified GitLab flow model. The workflow has to guarantee CI/CD that is, 1) expect a lot of commits everyday and they are expected to be moved into production ASAP, and 2) expect that the dev branch is messed up.Say developers only have access to Looker-dev instance, which points to the dev branch, they simply CANNOT create feature branches from other branches) Looker developers prefer to develop in Looker UI, which puts some restrictions on git operations (e.g.How can I resolve this issue? There are a few other restriction comparing to software engineering work: If I create feature branches from prd, Looker simply tells me that remote and local are not synced, which makes sense because dev is always different from prd. If I create feature branches from dev, and because dev is always messed up, it's very difficult to merge the feature branch into either of the two stable branches. However I have a big issue in Step 1 - should I create feature branches from dev or from prd/ stg? I have tried both and neither works perfectly. This time there is a human approver to approve the PR. Step 3: A checks that everything works as expected in stg, and creates a PR to merge the feature branch into prd.This time a github action is triggered to perform some automated validation and tests Step 2: A checks that everything is fine in dev and creates a PR to merge the feature branch into stg.Step 1: Developer A creates a feature branch from dev, say, A_feature_A1, eventually it gets merged into dev.prd is final and should be guarded by a human reviewer.A merge into stg should be guarded by automated tests, but not by humans stg is regarded as a stable environment where developers need to prove that their code works in such an environment before being merged into prod, a second stable environment.Basically we cannot afford any model that requires a big merge from somewhere to stg or prd (in a team of 50+ developers, even a daily merge is too problematic) We cannot afford a release branch method because merging the release branch into prod is a nightmare.dev is essentially a volatile sandbox and can be re-created rather quickly from prod if any critical file has been deleted.We also have three Looker instances that connect to one of them The github repo has three branches: dev, stg and prod.I have read all models in this page but none really fits my requirements. I'm creating a CI workflow for a 50+ Looker developer team.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |