RFC: Plan mid-term & long-term deployment strategies (CI)

[RafaelVidaurre]

Let's discuss what our long-term and mid-term setup should be in terms of CI / Deployments

mid-term: When we have time to polish and make things better
long-term: When we need to scale and need better control over services

[Grsmto]

We identified a couple of issues related to the current deployment process:

• Builds and deploys are both happening on Azure DevOps but it doesn't let us have the deployment process under source control (.yml file-like) which means anyone can connect to Azure GUI and change it without code review. That might be an issue as the team increase and we start splitting responsibilities. Ex: a new dev wanting to deploy a new package that break the deployment by mistake.
• Packages are deployed in different 3rd party service like Heroku and Netlify. These are not supposed to be used for complex ecosystem (multiple apps, monorepo). We spent a lot of time getting the deployments to work and the setup is quite fragile/hacky.

To address these two issues:

• We should consider separating CI E2E tests (Azure DevOps) and CD in two separated services:

  • E2E tests on Azure DevOps (CI) could be kept isolated and managed by @josepmc .
  • Packages deployment (CD) could use a service like TravisCI that will then be managed by this repository (through a source controlled .yml file).

• We should also consider moving away from Netlify/Heroku to have a more straightforward deployment process and being able to easily add new packages. We could use services such as AWS, http://Now.sh, etc.
  This can be done in a longer term.