Hacker News new | ask | show | jobs
by thirtythree 2070 days ago
We do this in work and it's not great in my opinion.

There can be issues with package versions compiled to the db. It makes continuously integration harder. We do automated builds and testing in the application layer but we don't have anything in the db layer. It's harder to create a new environment (for a developer who does not have full db permissions). Business logic ends up in the stored procedure layer AND the application layer.

2 comments

Including a real DB in continuous integration is a must for any development IMO. (And these days usually very easy to throw up a database using Docker -- each of our full CI runs runs in 2 minutes and does hundreds of "create database" calls and populate real SQL databases from scratch..)

For instance:

1) You want to implement idempotency in your backend by using uniqueness constraints in your DB 2) That's important to test 3) That's not really tested unless you include a real DB

After including a real DB in our CI setup I will never move back.

I use a Docker instance for localhost development, so much easier.

There are so many problems that can occur in that communication to the database, it's invaluable to test it

> for a developer who does not have full db permissions

Are you using a commercial database (SQL Server, Oracle, or similar?). With open source databases this is non issue as developers can run a complete instance locally with full permissions, completely isolated from prod/staging servers.

It looks like even the expensive commercial databases have docker images that would be okay for development purposes:

* Oracle Express: https://github.com/oracle/docker-images/tree/master/OracleDa...

* Sql Server: https://hub.docker.com/_/microsoft-mssql-server

* DB2 Community: https://hub.docker.com/r/ibmcom/db2

* Sybase: https://hub.docker.com/r/nguoianphu/docker-sybase