Proposal: Combine server, admin and embed into a single repo

[aszenz]

My first experience is working with three different repos is very cumbersome, I think combining them into a single mono repo maybe a good thing long term.

It would definitely simplify making cross-cutting changes and testing all three components locally (both manual and automated).

Mono repo style projects are common in the javascript world and popular tools to make them are yarn workspaces or the upcoming npm workspaces

Pros:

• Simplifies tooling setup, provides consistency across repos, works as a single product
• Makes it easy to contribute and perform cross cutting changes
• Avoids BC breaks between different versions of repository packages

Cons:

• Repo becomes bigger, cloning takes time
• Some migration effort and changes, including deployment

[aszenz]

@supermacro Let me know ur thoughts on this, not something really necessary but just a nice to have.

[supermacro]

My main concern is around automated deployments. What do CD setups look like when you have different "things" that need to be deployed to different places and in different ways?

[aszenz]

In essence you have different workflows (build steps) for each deployment and then you need to pick some logic to trigger the right workflow for a code change (code push, merge or tag).

The individual workflows can then be totally different and deploy using any method they need like push a docker image or send code to s3 for deployment etc.

There are three main ways I have seen it done:

1) Pushing to a branch say master and then detecting changes inside a top level path (like say server) then starting a workflow script based on that (so if the pr changes a file in server folder then only the server workflow is run, if it changes both server and admin then both workflows are run).

This is supported by github actions automatically using

on:
  push:
    paths:
      - "web/**"
    branches:
      - master

2) Pushing a release tag or creating a release and then checking the tag name to decide which workflows to run. This is a more manual way to do it.

name: Deploy

on:
  release:
    types: [published]
steps:
  name: deploy server
  if github.event.release.tag_name == 'server.v2' # this step is only run if tag name is server

3) The simplest way is to always deploy all services, on every push/tag, this is a bit inefficient but ensures that the services are always in sync and up to date.

[supermacro]

Ok, makes sense. I am ok with this. But not the highest priority. I think after we ship the MVP we can dedicate time to migrating things to a monorepo.

[supermacro]

Related issue: https://github.com/parlez-vous/embed/issues/33