A lot of documentation exists on CI and its benefits. Can anyone share some best practices on how to handle manual changes in environments (which are tied to a code change) along with automated deployments on environments? Is there an automated and elegant way to handle this?
When I say manual changes – it could be database changes (DDLs, DMLs) or changes in an admin console, setting a JVM property etc. Manual changes like server configurations, etc. usually end up stored in a config file of sorts. Try baselining those and pushing them out with the automated deployment.
DDL and DML changes are a bear. One solution is to have the DB server dump the DDL into SQL and DML into flat files. After deploying your DML and DDL to the production environment, generate the dump files, then bring them back to your development environment. Delete your DML and DDL and insert the dump files into source control as a database baseline. Now, in your development environment, you can blow away your database and restart by running the baseline and then any extra DML and DDL you’ve created since then, and when it’s time to deploy, you just deploy the extra DML and DDL (not the baseline) and restart the dump cycle.
I would advise against deleting the DDL and DML files, though. Keep them in the source control, and let them be a part of the baselining, to keep the change history complete. Every bit as important as source deltas. These issues are not new, and there are existing solutions. The process that Rob describes for databases is similar to that done by Liquibase – which works really well. There are benefits too, not just keeping *all* source, including DB scripts in source control. Additionally you can automate roll forward
An enterprise class deployment tool like uDeploy is built to allow automated deployment of all the pieces/parts of an application. However, in cases where you can’t get the DBA’s to allow automated application of DDL and DML,