Test as much as possible before deployment
Deployment isn't cheap. Even if the deployment is fully automated and pushed automatically from the commit it still takes time to deploy, it prevents any use of the development environment while deploying and if you deploy a broken application the development environment is stuck until things get fixed.
This depends on the kind of integration tests you have, obviously. A standalone component (for example, a message parser that stores things in a database) does not have to be deployed for integration tests to run. If you are doing UI-tests you obviously DO need to deploy to some environment to run those tests.
Run as much tests as you can during the build, and only deploy to run those tests that need the real system deployed to be able to run.
In-memory databases are great for unittests, not so much for integration tests
The advantage of in-memory databases is that they can be set up and torn down quickly and have a high rate of turnaround in your tests. A lot of people favor testing things like ORM-mapping and repositories with queries on in-memory databases and run integration tests on actual databases. I think that's a very sensible approach, but it's a very personal thing. If your tests are fast, running on an actual server is better (because the closer your tests are to the actual production environment, the better they are).