deploy to azure webapps

[eatyourpeas]

Outcome of sprint today that we are now ready to have a development webapp and database.

@mbarton should we create a staging site also with a view to adding live nearer the time?

[mbarton]

I think we can simplify and streamline things a bit. I was thinking perhaps we have two environments following the Guardian CODE/PROD split:

• PROD
  • Standard continuously deployed on every merge to main
• CODE
  • A combination of dev and staging - the "do whatever to it, it doesn't matter" environment
  • Also deployed on every merge to main
  • Developers can ad-hoc deploy their branches to it to test changes in a deployed environment
  • Merges overwrite whatever was last deployed

For pretty much every deploy we've done to E12 since I joined merging through staging has been a formality so I'm not sure how much value it buys us? For changes that require sign off from the wider team we should introduce them gradually behind a feature flag before enabling them - allowing us to test they work correctly against real data anyway. In the unlikely event we merge a destructive change accidentally we can restore from our last point in time backup.

Database migrations might make this a little tricky. It's easy enough to apply them automatically during CD but for the CODE environment we would have to roll any changes made during an ad-hoc deploy back when we deploy the next merge to main. Not insurmountable but I'm not sure exactly how much tooling to add in that area - it could just fail the deploy I guess and nag us until we go in and fix it manually ourselves.

An alternative strategy would be to deploy "feature environments" automatically for each PR. But that would really require us to commit to infrastructure as code so I'm inclined not to worry unless we end up ad-hoc deploying to CODE for every change.