|
I'm not sure if my workplace is "typical", but what we do for local development is only to use containers for dependencies, such as the database, or localstack (an AWS emulator). We have bash scripts that can set up and tear them down, using docker compose. Typically, we create a database container and then use it until we need to restart it for some reason, such as if the schema has changed. There's a shared repository we use that hosts all our migrations and has a script to refresh a set of schema files that define our current schema by running the migrations against a fresh, empty database container; this repository is referenced by our code repositories as a git submodule. We have one shared database that multiple apps use, and the above setup has worked out reasonably well for us. It's not terribly fancy, and I'm sure there are better ways out there we haven't discovered, but we have a good amount of flexibility. Also, that's all just for local manual testing/exploration -- we also use Java's "testcontainers", which spins up its own containers (though basically the same idea) for automated tests to run against. Testcontainers lets you specify how it restarts the containers -- after each test class, after each test run, or not at all. Restarting the container is pretty slow, so we have it set up to just drop and recreate the relevant databases within the container. For deployment, we've used different platforms that deploy apps in containers, but we don't manage the containers directly. Also, I've tried the "develop in a container" thing but only on rare occasions, such as to work around a MacOS bug that makes CIFS file sharing horribly slow. Technically that was a Vagrant VM, not a container. Haven't had much luck with it otherwise -- it seemed like more trouble than it was worth (it's the awkward file syncing that's the barrier for me). |