> This comes into play in a few areas: > > 1. Automated Testing > 2. Large (20+) development teams > 3. Multiple projects happening at the same time > > Let's key off of a those. > > 1) Automated Testing-- > Automated Testing can use a Code Revision, and Database Revision to > determine when a bug is introduced, and why, then, automatically scale back > to the working copy, alerting the developer in charge of the code commit, > who can then fix it, put it back up, and Automated Testing can continue.
if you integrate your db migration tool into your automated testing environment then this could work for you. However, I just add the scripts that need to be run for the specific database version to my automated test/build scripts. In svn i just make sure that my db and source code are the same for each release. I tend to store the database version in the schema comments so i can query that information out when needed so that my automated test knows which scripts to grab. This allows me to run the appropriate scripts for the tests and builds. However, if the DBA is doing the work then each code base revision should be up2date with all the necessary changes - providing me 1 script that needs to be run for each version increment. > 2) Large Development Teams-- > When you have 20+ people working off of the same Development database, > changes get lost and some people may over-write others database updates, or, > cause an error and restore a table from a backup -- losing what other > developers have done. It solves the need for communication between > developers every time they need to do anything with the database, and saves > a lot of time in troubleshooting and correcting errors. i guess a tool could help here; however, i have worked on teams with 60-100+ developers where database are managed without the aid of a tool. In this scenario we use other methods outlined by ISO and other standards. This is done more for traceability (documentation) then other reasons. Here we use DBCRs (DataBase Change Requests). these are documents that are used by DBAs to manage the database. When you have 1000s of tables per schema and upto a hundred schemas to manage this helps with the overall process. Here the changes are submitted by developers to DBAs for review and overall effect on the database and other systems in the database. Basically, impact analysis on the system before the changes go into the database. this also allows us to make sure the database standards are upheld in each change request. After the DBCR is completed the DBA assigned to it will make the script and apply it to the database. Only a few are allowed to make the changes. This helps to prevent developers making mistakes or adding changes that might impact other systems or sub-systems. Once completed they are added to 2 types of scripts: upgrade scripts and overall installation scripts. > 3) Multiple Projects-- > When you have, 3, 5, 10, or more projects going on simultaneously, > someone may make changes to a database (drop this column, add this > replacement column) on a Project A slated for 2 weeks out, and another > developer may have Project B going for 1 week out, and wants to push out the > same table, without worry of dropping a column for a project that won't be > ready for a week longer than the current deadline of Project A... This > causes huge concerns, such as multiple developers using the same sandbox, > modifying code for 2 different projects,and pushing out errors.. > > There are more, more in-depth reasons, but these stand out the most. You > don't trust the Developer to remember every line of code they modified after > 3 months on a project, why would you expect them to remember every Database > change? I dont see how the tool will help with this type of issue. Meaning if a developer makes changes to the database and those changes get added to the migration tool then they will propagated throughout the build and deployment process. I think this goes back to the issue of communication in the project that you mentioned above. Which needs to be overcome with additional steps that a tool cannot manage. there needs to be a time and place where these items get discussed and added or removed it needed. One thing we have done to help facilitate this process is have specific individuals assigned to managing the database. Allowing any developer access to modify the database without express permission or doing an impact analysis is asking for trouble. In reading about CodeIgniter's database migration tool - it allows the developer to do the following (granted i only reviewed a small portion and have not used the tool so this might not be everything): '* Each individual in a team is supposedly working on their own installation of your system. * Whenever a team member makes a change to their database schema, he extracts that change into a class called a “migration”. * When he is done working, he can move those “changes” to any other environment (the “live” environment, for example) and “install” each migration' - CodeIgnitor One thing that is unsettling to me is the fact that any developer can make changes and add that to the code base. Here in lies the issue - (IMHO) not every developer should be making the changes to the database that could be added to a production db. I don't want jr developers making changes to my db. I think your statements are true that there needs to be tons of communication and i think there needs to be something to prohibit developers from making changes without some method to manage those changes. For this reason I am a big fan of code and database reviews and analysis before that code is introduced into a production baseline. -- thebigdog _______________________________________________ UPHPU mailing list [email protected] http://uphpu.org/mailman/listinfo/uphpu IRC: #uphpu on irc.freenode.net
