driver = com.mysql.jdbc.Driver
url = jdbc:mysql://localhost/ebank
username = scott
password = tiger
verbose = true
dropFirst = falseHowever you can override any of these properties from the command line, which makes it easy to set
up a Jenkins build to update different databases.
Other similar commands let you generate an SQL script (if you need to submit it to your local DBA for
approval, for example), or rollback to a previous version of the schema.
This is of course just one example of a possible approach. Other teams prefer to manually maintain
a series of SQL update scripts, or write their own in-house solutions. The important thing is to have
a solution that you can use reliably and reproducibly to update different databases to the correct state
when deploying your applications.
12.2.3. Smoke Tests
Any serious automated deployment needs to be followed up by a series of automated smoke tests. A
subset of the automated acceptance tests can be a good candidate for smoke tests. Smoke tests should
be unobtrusive and relatively fast. They should be safe to run in a production environment, which may
restrict the number of modifications the test cases can do in the system.
12.2.4. Rolling Back Changes
Another important aspect to consider when setting up Automated Deployment is how to back out
if something goes wrong, particularly if you are thinking of implementing Continuous Deployment.
Indeed, it is critical to be able to roll back to the previous version if required.
How you will do this depends a lot on your application. While it is relatively straight-forward to redeploy
a previous version of an application using Jenkins (we will look at a technique to do this further on in
this chapter), the application is often not the only player in the game. In particular, you will need to
consider how to restore your database to a previous state.
We saw how it is possible to use Liquibase to manage database updates, and of course many other
strategies are also possible. However rolling back a database version presents its own challenges.
Liquibase, for example, lets you revert some, but not all changes to the database structure. However
data lost (in dropped tables, for example) cannot be recovered using Liquibase alone.
The most reliable way to revert your database to a previous state is probably to take a snapshot of the
database just before the upgrade, and use this snapshot to restore the database to its previous state. One
effective strategy is to automate this process in Jenkins in the deployment build job, and then to save
both the database snapshot and the deployable binary file as artifacts. This way, you can easily restore
the database using the saved snapshot and then redeploy the application using the saved binary. We will
look at an example of this strategy in action further on in this chapter.