---
# System prepended metadata

title: v3 Blacksmiths Show & Tell (4/15/22)
tags: [' show & tell', ' blacksmiths', v3]

---

---
tags: v3, blacksmiths, show & tell
---

# v3 Blacksmiths Show & Tell (4/15/22)

## Git Workflow

- How do we want to work?
    - `develop` as base branch
    - merges into `master` have CI/CD
    - small feature and bug branches off `develop` 
    - PR into `develop` for each feature
        - `feature/feature-name`
        - `hotfix/fix-name`
        - PR would include the link to the issue/card
- Rebase & Squashing Process
    - What do we want to do with this?
    - Squash and merge process and delete the branch after merge
    - Rebasing `develop` while working on feature branch to help keep up to date
    - Keeping branches up to date
        - Commit often and merge in where we can
        - How do we tie this all in to our Review process?

## Review Process

- How many reviewers do we want?
    - Start with 1
- Every branch has CI on it so that each branch is fully linted and fully tested
    - This would run and then the review would be about the code
- Deluxe Review: have folks sync on specific topics where requested by the author
    - Pattern PRs
    - More substantial PRs -- share knowledge and establish our patterns
    - Code reviews in meetings
        - Schedule these as they come up for these types of reviews
    - Can we set up notifications in the Discord? Set up a **code-review** channel?
- CI & Review Enforcement:
    - Enforce this via GitHub Actions
    - Prevent merging unless CI passes
    - Require at least 1 Review
- SLA for Review:
    - Goal to get a review within 24 hours as a goal we aim toward

## Versioning

- In libraries, when we push to master we should bump our version
- Can we enforce this with linting?
- Can we automate this via GH Actions?
    - We'd have a failed build on npm if we don't

## Questions

- Having the checks in CI, but what do we do if the deploy breaks on a different library (as opposed to one directly impacted in the PR)
- Can we have the CI only check impacted or changed packages?
- Tests and checks:
    - These should also exist locally
- What do we do when things break?
    - Can keep pushing to the branch even if the CI fails -- we'd not *merge* things with failed builds
    - Process:
        - Ping an ops person or a 'lead' for each package
- How would we handle multiple PRs per day?
    - Balance of feature branch PR approach with review speed
- CI for hotfixes:
    - We won't be worrying as much about a QA/prod environment as we're pre-release, but what do we want to do if we have a hotfix in prod?
    - If it goes to master, we'd want to see how we re-merge back to `develop`?
    - Would we want to do a promotion process instead?
        - Depends on policies for how long things hang out in develop?
        - Longer standing feature branches -- everyone works on this for larger features
        - Every branch creates a QA environment -- anything merged into staging is then ready for prod
- How often do we want to merge `develop` into `prod`?
- Code style guide / contributor guide
    - https://daohaus.club/docs/devs/goals-and-ideals
- Rage vs. Sage
- We should probably revisit our `.gitignore` and review 