Echo JS 0.11.0

<~>

tracker1 730 days ago. link 2 points
While I appreciate the approach, and agree that you should have a version visible (I'm in favor of in the footer)... I think that trunk based development with a reduced level of environments is another approach worth considering.

This tends to make a lot of people uncomfortable, especially if you've never experienced the process before.  In the end, the point is to dramatically reduce the friction between development and production.  Not having long lived feature/release branches in favor of always releasing.  It's far easier to fix a nearly immediate issue quickly than it is to maintain many long-loved stages of releases and branching.

I worked in an environment where once you pushed to master, assuming automated tests work, it's in production within 5 minutes.  As we onboarded other teams, a lot of people would in fact break production.  That said, it was always quickly fixed, and the lesson was learned only once.  Developers get a lot more conservative in their approach when you *know* it needs to work right the first time, or behind a flag and not break.  Testing becomes *more* prevalent when you can't rely on layers of test/qa/uac/demo/deploy stages or feature branches that live for weeks/months.

Where I'm working currently, we're on a Kanban approach and are currently reducing our environments from 5 to 3 (dev/test/qa/demo/prod) to (test/demo/prod), and likely will just have test/prod within a year.  Development is trunk based from master, and paired development is the norm.  It's been really refreshing and we're pretty high performing in terms of getting stuff done, increasing quality and delivering features.

Other things that help, is being able to spin up local environments that are close to production... Docker (and WSL for windows devs) has been invaluable here.  Being able to docker compose up and have a complete dev environment in under a minute is really helpful.  Git commit/push hooks and github actions are also helpful in gate keeping.