> Hiding in-progress work behind feature flags — which is often part of continuous deployment
There's many ways to do this, of course, but something I've found works well is just making it frictionless to deploy feature branches to a "dev" environment. You can test changes (especially those that integrate with other systems/services) but still keep everything isolated.
This is also great because when applicable you can take screenshots/gifs of the new feature actually running (not just on your machine) for the pull request.
That helps, but in my experience it’s much more useful to be able to decouple deployment from _delivery of features_.
Want to change the layout of a page? Normally this would require at least a little coordination with, say, customer support or marketing teams. We don’t want to hang around waiting for schedules to line up, so it’s often easier to simply deploy the feature behind a flag - it means it can, for example, be rolled out to some customer cohorts before others (beta testers?), easily rolled back, made live by the product team rather than engineering - that sort of thing.
Though of course a dev environment is _also_ incredibly important!
That's fair.. it really depends on the situation. Too many feature flags can get complicated in the same way too many open, long running branches can. It's nice to have the option of either. Feature flags I think are a bit easier to forget about and leave in the code; branches are obtrusive and you constantly have to merge new code in to keep them updated, pushing dev to get rid of them ASAP.
All my work lately has been done in branches, which then merge to master, and master gets deployed to production as needed: sometimes immediately with a single bug/feature, sometimes several bundled together after a week or two. Depends on severity, other work occupying the team (especially QA), and which software/system(s) are affected (eg. core software, infrastructure, or internal tooling). I am pretty sure we've only used feature flags in the core software, and only a couple times. Of course, that software is hybrid cloud/on premise, and as such we have strong version numbering for every release, so features/changes naturally tie to the customer-facing release numbers.
There's many ways to do this, of course, but something I've found works well is just making it frictionless to deploy feature branches to a "dev" environment. You can test changes (especially those that integrate with other systems/services) but still keep everything isolated.
This is also great because when applicable you can take screenshots/gifs of the new feature actually running (not just on your machine) for the pull request.