#Setup for a small team working on a Medusa project

2 messages · Page 1 of 1 (latest)

signal sandal
#

Hi! Me and my two colleagues are looking to spend some "20% time" getting our current third party e-com engine replaced with Medusa - as an experiment and to get a feel for "how hard would it be...". Our setup right now, where we only really own the storefront part of this thing, is quite simple: we all work against the QA environment at our third party vendor. The only thing running locally when doing dev work would be our own storefront.

When doing Medusa development as a team, and having access to modifying both the e-com backend/admin, the actual DB underlying it and the storefront brings some new challenges that we haven't had to face for a long time.

What is the best setup for collaborating on a Medusa project?

I would imagine that you'd want to run the parts that you are working on locally but not necessarily every part? Ie. run the storefront locally against the QA medusa app and thus QA db if you only do storefront work, and run the medusa app locally if you do work on that... and so on. But how to handle db content things? Migrations only handle db structure, right? Any neat flow of also getting test products / entities shared across local db instances, maybe via the QA one?

Anyone care to share their "team setup" with us?

gray quail
#

Generally the approach has overwhelmingly been everyone has there own Postgres and runs without redis in dev. Then start the storefront and backend locally. Write seed scripts to inject any data you need and execute those beforehand.

You’ve got Medusa features to work with: scripts, migration-scripts.

npx medusa exec {path to script}.

If you want to automate setting up the entire environment dbs and redis and any other services locally then you could use docker.