StrataFrame Forum

How to: Automating DDT updates for customers

http://forum.strataframe.net/Topic23410.aspx

By Edhy Rijo - 6/8/2009

Hi guys,



I know that we can use DDT packages with the DatabaseMigrator Class, but I have the following concerns:



How to control versioning of the package to be installed at the customer's database? in other words, how my update process will know that a particular database needs to be updated?




Also how to check from my application that the database is properly updated to the required version?




I am guessing that I would need some sort of version table in my database to hold the database version and check on that field value to update the database or refused my application to run if the database is not withing the required version. Does this make sense? how are other managing this stuff?



Thanks!
By Aaron Young - 6/8/2009

Hi Edhy,



What you have described is basically what I do:-



1. I have a version table which is deployed by the DDT with a single record. This record contains an integer version number (don't use a decimal as there is a bug in the DDT which causes a decimal to be deployed as an int, i.e. 5.13 would be deployed as 5).



2. My application also contains a reference to the current database version number.



3. When the application runs it checks for the presence of a version table. I have to do this as my application upgrades earlier non-SF systems so it could be a first time install of my SF client on an existing database. If the version table is not found it warns the user it can't proceed and opens the DDT wizard. (My package is password protected to ensure a novice user doesn't get their hands on it). When the wizard closes, it checks again to ensure the database was upgraded - if not the application warns the user and exits.



4. If the application version is greater than the database version then the user is warned and the DDT wizard is opened. If the database is not upgraded the user is warned and the application exits.



5. If the application version is less than the database version then I allow it to proceed as a database upgrade will never stop an older application version from running. However, I would expect our setup routine to have automatically detected a new client version on our website and to have downloaded and installed it automatically anyway so this is probably not an issue.



Not sure I have left anything out but it works very well.



Regards,



Aaron
By Edhy Rijo - 6/8/2009

Hi Aaron,



Thanks for the detail explanation of your process. It is pretty much just what I need for know so I will start working with this logic.



I will also need to add the same logic to my install setup file so this will be cover from both places, the installation setup and the application itself.
By Trent L. Taylor - 6/9/2009

One other thing that you may consider is making this part of your build process. We have a build routine that automatically builds the DDT package (you can do this via command line). Once built, we actually create a folder and copy the new package over for a type of version control. This way if we have to get back to version 1.0.0.5, for example, we have a DDT package of that build.
By Edhy Rijo - 6/9/2009

Thanks Trent, will take that into consideration.
By Ulrik Mueller - 6/9/2009

Hi Trent

Do you have a whitepaper on setting this enviroment up - so the daily builds can be handled automatic. 

I use the Publish project in VS to get the application pushed out to my customer, but today i have to handle the database updating manually, which I find quite anoying!

Regards  /Ulrik

By Trent L. Taylor - 6/9/2009

Well, there are a number of routes you could take here.  As you know, all development environments are different.  Some people have a commercial redistributable product, others are in house, etc.  So depending upon your needs the setup would change.

From what I can tell, you are manualy deploying things to your customer site on a daily basis.  So I would recommend a couple of things.

  1. Team FS Publish Build is good, but Automated Build Studio is better....ironic for me to say this as I am  HUGE TFS fan!!!  We use Automated Build Studio for our builds which allows us to pull everything down from source, rebuild, copy files, build installs, deploy databases...pretty much anything you need to do.
  2. If you are using the DDT to deploy your databases, then I would create a deployment program that deploys the package.  Using the database installer sample you can get the idea on this.  but you can create a program like this then add it into the build process as part of the deployment.

Just a couple ideas, hope it helps. Smile