4 ms·

At the agency where I work we have about 40-50 somewhat active projects at any time. Any given week I work with maybe 3 to 10 of them. It saves so much time to

At the agency where I work we have about 40-50 somewhat active projects at any time. Any given week I work with maybe 3 to 10 of them. It saves so much time to just pull down the repo, run "docker-compose up" and have everything running, almost exactly the way it's running in production. With the right node or php version, databases, Elasticsearch, Redis etc.

Silhouette 6y ago
The problem I usually run into with this sort of arrangement is the database. Every non-newbie developer is very aware of using source control with their code. A lot of developers are careful about managing the dependencies for that code as well. But for the database, you have a second asset that often needs to be synchronised with the code, and that means both schema and possibly records as well. Just deploying changes affecting both assets carefully in production can be quite awkward relative to a code-only deployment. You might need to do this in several stages, updating your code to allow for but not require the DB changes, then updating the DB schema, then maybe updating existing DB records, then at least one more round of code updates so everything is running on the new version of the DB. And you might need to make sure no-one else on your team is doing anything conflicting in between. Doing the same in a staging environment isn't so bad because you're running essentially the same process. However, for a development environment where you want the shortest possible feedback loops for efficiency, you need to be able to spin up a DB with the correct schema, and possibly also with some preloaded data that may be wholly, partially or not at all related to controlled data you use to initialise parts of your database in production or staging environments. It is not always an easy task to keep the code you use to access the database, the current schema in the database, and any pre-configured data to be installed in your database all in sync, and to ensure that your production, staging/testing/CI facilities, and local developer test environment are also synchronised where they should be.
- mediascreen 6y ago
  I agree that the database (and things like uploaded images) can be a challenge. For WordPress we usually sync down from production, to staging, to testing, to local (while filtering out PII). For other projects is't usually easier using migrations and seeding.
  - Silhouette 6y ago
    The challenge is how you keep your migrations, source code and any seed data synchronised, but only where they should be. There is often a need for any separate migration process/scripts to be synchronised with corresponding changes to the DB access code in the main application, so the models in the application code always match the actual schema in the database. For seed data, there may be some "real" data that should always be present but also some "example" data you want to include (and reset to a known state) for each test in an integration test suite. Etc. It kind of amazes me that there doesn't yet seem to be a way of handling this in the web development community that has become a de facto standard in the way most of us look at tools like Docker or Git these days.
- ywei3410 6y ago
  There's also mutual deployments which suck really bad i.e. deployment A needs to go out with deployment B; but if you haven't set up your CI with that facility (and, let's face it, the easiest way to set up a CI with multi-repos is on a per-repo basis), it can get really hairy.

Silhouette 6y ago

The problem I usually run into with this sort of arrangement is the database. Every non-newbie developer is very aware of using source control with their code. A lot of developers are careful about managing the dependencies for that code as well. But for the database, you have a second asset that often needs to be synchronised with the code, and that means both schema and possibly records as well. Just deploying changes affecting both assets carefully in production can be quite awkward relative to a code-only deployment. You might need to do this in several stages, updating your code to allow for but not require the DB changes, then updating the DB schema, then maybe updating existing DB records, then at least one more round of code updates so everything is running on the new version of the DB. And you might need to make sure no-one else on your team is doing anything conflicting in between. Doing the same in a staging environment isn't so bad because you're running essentially the same process. However, for a development environment where you want the shortest possible feedback loops for efficiency, you need to be able to spin up a DB with the correct schema, and possibly also with some preloaded data that may be wholly, partially or not at all related to controlled data you use to initialise parts of your database in production or staging environments. It is not always an easy task to keep the code you use to access the database, the current schema in the database, and any pre-configured data to be installed in your database all in sync, and to ensure that your production, staging/testing/CI facilities, and local developer test environment are also synchronised where they should be.

mediascreen 6y ago
I agree that the database (and things like uploaded images) can be a challenge. For WordPress we usually sync down from production, to staging, to testing, to local (while filtering out PII). For other projects is't usually easier using migrations and seeding.
- Silhouette 6y ago
  The challenge is how you keep your migrations, source code and any seed data synchronised, but only where they should be. There is often a need for any separate migration process/scripts to be synchronised with corresponding changes to the DB access code in the main application, so the models in the application code always match the actual schema in the database. For seed data, there may be some "real" data that should always be present but also some "example" data you want to include (and reset to a known state) for each test in an integration test suite. Etc. It kind of amazes me that there doesn't yet seem to be a way of handling this in the web development community that has become a de facto standard in the way most of us look at tools like Docker or Git these days.
ywei3410 6y ago
There's also mutual deployments which suck really bad i.e. deployment A needs to go out with deployment B; but if you haven't set up your CI with that facility (and, let's face it, the easiest way to set up a CI with multi-repos is on a per-repo basis), it can get really hairy.