Continuous deployment

[afeld]

While the Benefits release process works, it requires a decent number of steps (and thus time) to get a change/fix out to production. Moving towards continuous deployment could reduce that time/friction.

Acceptance Criteria

• Changes are deployed to production automatically, though not necessarily visible to the public

Additional context

Getting to continuous deployment would likely require feature flagging. (A funny intro to feature flags, starring a former coworker.) A benefit here is that features can be decoupled, and thus no longer block releases by virtue of being on the dev/test branches.

While we do have a number of features/integrations that can be enabled/disabled without a deploy (through environment variables or modifying the migration file), these are all binary state: on or off for everyone. Using a more sophisticated tool for feature flagging could allow features to be shown for some users, but not others.

[thekaveman]

One possible option for feature flagging: https://github.com/cfpb/django-flags (see Usage and more docs)

[thekaveman]

Also: https://github.com/django-waffle/django-waffle (docs)

[thekaveman]

Closing this in favor of the tag-based / deploy on release model, which has been working well in eligibility-server.

See #1527