views:

134

answers:

3

Tipically a deploy in production does not involve just a mere source code update (build) but requires a lot of other important tasks like, for example:

  1. Db scripts
  2. Configuration files (differents from test\production)
  3. Batch to schedule
  4. Executables to move to the correct path
  5. Etc. etc.

In our company we just send an email to a "Release email address" describing the tasks in order, which changeset need to be published (TFS), which SP need to be updated, db scripts and so on.

I believe there's not a magic tool that does these tasks automagically in order, rollback included; but probably there's something better than email that helps to keep track of releases in production.

Do you have any tools to suggest or practices to share?

A: 

How about something like SVN? You can put all of your code in a repository, then when you are ready to release from production bring your stuff over from test. Then you'll have very specific revisions with information on what happened. SVN keeps track of all of it.

wilbbe01
@wilbbe01 we use TFS as version control system.What i'm asking here is how to keep track of ALL the tasks of deployment.
systempuntoout
+4  A: 

When multiple tasks are required to support a full project deployment (and that's frequently the case, in my experience), I'd suggest using a build/deployment tool. I've used Ant in the past with great success, but know others who swear by Capistrano, Maven and others.

Using Ant, I wrote a script that would:

  1. Pull the specific revision I wanted from my VCS
  2. Create a tarball of the target directory on the remote machine (in case a rollback was required)
  3. Create a MySQL dump file of the database (also for rollback purposes)
  4. Delete the remote directory and SSH the new content just pulled from the VCS
  5. Perform various other logistical operations (setting file perms, ownership, etc.)
  6. Create a release branch on the VCS itself
  7. Create a tag with the appropriate version information so I always had a snapshot of the code base at that moment of deployment.

Hope that helps some. I've written a few blog posts about this that may (or may not) be useful. They're dated now, but the general information should still be solid enough.

Rob Wilkerson
@Rob Thanks for your detailed answer; don't you keep an history of your ant scripts?
systempuntoout
A history of my scripts? For each project, I have a `_meta/` directory where I store related components like deployment scripts (Ant), database DDL scripts, etc. In that way, yes, I keep a history. The property file I use changes for each deployment.
Rob Wilkerson
+1  A: 

You might be interested in the Team Foundation Build Recipes Website, that showcases some build scripts developed using SDC Tasks Library and the MSBuildTasks library

Franz
+1 for answering about TFS. We automate our entire build with MSBuild (from getting a clean copy of the source, building it, to producing a final installer). When released, we (a) copy the installers into a customer release folder so that we keep a copy of them separate from the build system, along with a text file describing the build, changeset, and which customer(s) it was released to, and (b) label TFS so we can easily return to the changeset that the build came from. (MSBuild auto-labels every build, but it's nice to have our own labels for actual releases)
Jason Williams