We are working in a very multi-language environment, and we have a lot of devops automation that sets up a dev checkout for work - creating databases, building Docker images, etc. In the end the user, not necessarily a developer, can open a browser and use the system. This system is composed of around 20 docker containers written in Java, NodeJS, Python, Go, C# and PHP.
We are using Flyway command-line for migrations in all languages, using solely SQL-based migrations. This solution is great for us, because it is completely language and framework agnostic. The same set of automation scripts are used for all projects to run DB migrations. Each project has a set place for where it's migration files are.
However, when it comes to loading the baseline fixture, currently we are using all sorts of home-grown hacks, and I would ideally love to use something mature and robust like Flyway for language-agnostic db fixtures.
Note that I am not referring to fixtures for unit tests here. These are for either manual or functional tests.
I have looked around, and couldn't really find anything that appears appropriate in this area. There are plenty of language and framework specific db fixture solutions, and perhaps one option is to simply accept that, and use a different db fixture solution for each language (and devops-automate around as such).
So my question is? Is there anything like this that I've missed? To help clarify, I'll list a few features that explain what I'm looking for:
- FAST - Ability to run
db:reset
very frequently. Edit test fixtures, rundb:reset
and test the result during development of the fixtures themselves. - Easy syntax for expressing the test fixture data. So for example simply using SQL isn't ideal here - for test fixtures it's not very readable or maintainable. Relevant bits of data are spread over different INSERTs, auto-generated primary ids must be manually maintained, diffs aren't very clear (version control), etc.
- Multiple files - as the complexity of the fixtures grows, like migrations or code we don't want to stay stuck with one huge file. This in turn may give rise to ordering issues with a naive solution.
- Error reporting - being told that there was something wrong with the query at
fixture.sql
atline 123
is far less useful that being told Book B can't be inserted because Author A isn't defined anywhere. - A nice to have would be an easy way to update the fixture after migrations are added - change the baseline to be
LOAD CURRENT FIXTURE + RUN MIGRATIONS + DUMP AGAIN
.
Is there anything that comes close to the above and isn't tightly coupled to a specific language or framework?
Aucun commentaire:
Enregistrer un commentaire