My preferred development workflow for 2024: 1


My preferred development workflow for 2024:

1. All devs have their own DB instance so we don’t conflict with each other. The DBs run locally, and can be reset via static SQL scripts via a single command. The SQL scripts are committed to source control. This way, we can code without internet, demo the app reliably, reproduce bugs, and write fast, reliable tests.

2. Create a short-lived feature branch for each ticket. Each pushed commit runs tests on CI. CI auto-deploys a dedicated ephemeral (short-lived) environment with a unique URL for each feature branch so people can test and approve *before* merge. Thus, no separate shared environments like UAT or staging are typically required.

3. When a PR is approved, we merge to main. The CI server auto-deploys the main branch to prod. If the feature isn’t ready for public use, hide it in prod via a feature flag.
Benefits:

1. No shared state during dev. So we don’t conflict.

2. No internet required. So I can code anywhere.

3. Easy approvals. Anyone can see my WIP at any time at a dedicated URL.

4. No post-merge approvals. So anything committed is worthy of prod. This is huge. We don’t waste time coordinating the batching of work or planning releases. We know code works right *before* merge. So when it’s merged, it’s deployed.

View original on X