Personally I am a big fan of TeamCity here, though I have heard some good things about Hudson / Jenkins recently. I would argue that after source control, continuous integration is the most important thing you can do for your development process. I’d actually argue it the other way if you didn’t need source control to make CI work.
1) Do you use a deployment tool for releasing the app? Like Jenkings?
a) If yes, does your deployment tool takes care of all the process automatically viz. New Database setup on the targeted server, applying folder permissions etc.?
b) Is there any manual deployment involved anywhere or the entire deployment process is automated?
Yes, we use TeamCity currently. I have used CC.NET in the past and kicked the tires on Hudson / Jenkins. Specifics depend on the application, but all the newer stuff is capable of doing a scripted install of the database from a de-novo environment with a few basic presumptions about environment. Permissions haven’t been an issue but we’d also handle them via scripts if required.
Operational goal is to make it so the application can be deployed completely hands off. So ideally there are no manual steps. We do allow some legacy applications that are not setup for easy database deployment and migrations to dodge that side of the coin but at least the codebase is entirely mechanically built and deployed. These apps also have a very stable database structure so this typically is not an issue.
We haven’t quite got to pushing production deployment completely in teamcity for a variety of reasons. Mainly network topology and security make it a challenge. That said, figuring out a good way to handle this is on the list of goals for 2012.
2) If you are releasing your application for testing purpose to the QA department, do you build new database for each release?
a) what naming convention do you follow for the database name if the above case is true?
We typically take production data and migrate the changes when we get to the QA part of the process. Typically separate environments on separate db servers so we’ve never had any naming issues / conventions. But everything has it’s own configuration so we could call the databases anything we’d want.
3) If you are using a version control system (SVN, Mercurial, Git etc) do you maintain the database version also?
a) How often do you commit your database to the repository? Is it every time there is a release or is it every time there is a change in the structure of the database?
For the newer stuff, we are using database schema migrations so there really isn’t a change unless there is a commit. Build automatically migrates things so the data is evergreen. Apps are designed so they make zero assumptions about the data in the database, just that it is there and the correct version.
4) Assuming there was a project that was made live a couple of months back, now the client comes back to you requesting for some changes, would you consider the code base that is on the live server to be the latest one or the one that you have in your version control system to be the latest one?
a) How do you manage the content that is on the live server which was uploaded / added during these months by the users / admins of the website? Do you download them all and commit them to the version control repository?
We setup most things so that there is zero filesystem interaction so it would be difficult for the app to get out of date while in operation. Releases are tagged in both SCM and teamcity. Finally, for configuration changes on servers, we use SVN to version the configuration files so we can pretty easily sanity check for configuration changes.
We have a few static sites run by rouge outfits who refuse to use modern tools. Those also happen to be under version control though the site owners don’t know about it.
5) And last but not the least, could you please refer me some documents where I can learn a standard deployment process that is being followed by companies?
I don’t think there is a standard, or even an emerging standard. Real issue is that deployment is a no man’s land between development and operations that no one wants to own.
