Thanks for the info. There are a few different ways that our customers are doing things similar to do this, I'll run through a couple below. Very happy to hop on the phone to talk more too.
One way is to use Red Gate Deployment Manager
alongside SQL CI. This can be setup so that whenever you make a commit to either the application or database the CI server will create two packages. One that contains a build of the code and one which contains the scripts folder representation of your database. These are then both passed to Deployment Manager as a 'release' (a specific pair of versions of the DB and code). This release can be deployed automatically to your dev/CI environment . The same release can then be deployed as a 'push button' deployment to QA, staging and production environments. It's a good match if you're planning to run a continuous delivery approach. It ensures that the same pair of versions of code and database end up together as they move through each environment. Diagram of Deployment Manager Workflow
Another approach is to use a version control release branch for each environment. When developers commit code to the 'dev' branch your CI system can build to the dev environment using SQL CI. When it's time for a QA deployment then you can merge the required code onto the QA branch and have the CI system deploy the CI environment. You can do that for both the database and the application (either in separate repos or as a single combined repo). It's a bit more fiddly to work with in my opinion.
There's a Stack Overflow thread
with a few diagrams that match this 2nd approach.
Hope that helps