Versioning Code and Database
From LeonWiki!
Purpose
Allow SVN to automate the process (as much as can be) to tracking and applying (merging) content changes from a joomla production site to ongoing development on a dev tree, which is then tested on a staging branch and then released to production. (The database is updated by tracking/changing the versioned sql file that results from import/export of the database)
- Advantage: much simpler and less error-prone than original approach.
- Use svn to create a branch that represents production when you've deemed the site to be good. Then dev continues on the main branch, while the production branch is not disturbed. At some future time, the production site code + sql is pulled down and overlaid onto the production branch. Then merge production -> main branch -- import sql code on main branch to dev db and test!
- Constraint: SQL file must be up to date on dev</b>
The config file versioning (or not) scenario
- I think it is better not to version configuration.php, .htaccess
- These files shouldn't change at all since we are now using SVN during the entire process - from dev to staging to release and to production -- we only need do an svn switch of our working copy, so the directory we are in stays the same, only the underlying code changes. Hence, the paths don't change until we go to production. If they are versioned, then when an svn update is run on production, they will have to be changed. If they weren't versioned then only the first time do they need to be changed.
- Any changes that might take place can be easily manually ported/merged.
- UPDATE: I am versioning them, but the good news is that since I had to change them on the first release, they are now modified and when we do the SVN switch to go to the next release, they are never overwritten since they are modified. So all the work is taken care of by subversion....yea!!
Implementation
************** TAKE BACKUPS of PRODUCTION DATABASE at the end of EVERY DAY **************** (This is now under a cron job that should be mailed to me each evening)
(wc = working copy = your local copy)
Using phpMyAdmin on both dev and production sites
UPDATE:IMPORTANT! To remove components/modules/plugins from joomla when they are versioned:
- First: use the install/uninstall in joomla to remove the component/module/plugin (This process will remove it from the wc)
- Now that the wc does not contain the files, we can't delete them in subversion until our wc has them. So we must update those files from the repo (by issuing 'svn update'), which will restore them to the file system (in our wc), and then we can delete them from the repository using subversion ('svn del <directory name>').
- Update: I've now been through two releases and one of them I had removed artioSEF and some other components that I wasn't intending to use. Experience shows that in the merge it can be difficult, if there are conflicts, to discern what I should keep from my db file and what I shouldn't. It might be easier if I removed the component on the production site (which would remove any db tables etc). Then before doing a release, I would remove the component on the dev site, and then the db's would be in sync with respect to the removed component. Of course all the above rules would apply in terms of removal from BOTH the db and the versioned file system on BOTH sites.
