We’ve recently launched our Yii powered application to a client and already we’re receiving feedback on improvements and feature requests. As we continue to develop the app the need to upgrade our client to new code with amended database tables / columns will sure enough come so I’m reading around on how-to’s.
Any tips or tricks on how to seamlessly upgrade our client & Yii application - I’ve come across ‘migration’ and wondered if the community has any ideas?
Thanks in advance.
All our yii apps are using great yii-environment extension. Combined with some mod_rewrite rules in .htaccess our apps switch environment based on server name (keep in mind there are some things to double check before you go live). All schemas modification are stored as yii migrations.
Git repositories are managed in "A successful Git branching model" way. Currently, we use BitBucket as our "central server". We also use Git as a file transfer tool. Live pages are tracking master branch, while testing versions are tracking develop or release branch. That way, we can pull latest version to test server, run tests, do some manual verifications and if everything is green, we pull latest tag to live page. In case of any problems, reverting to previous version is as easy as pulling previous tag.
Db are little more problematic, because yiic migrate will update db to the current version but when downgrade is needed, one needs to supply a relative or absolute version manually. Fortunately that’s easy to solve with a script that checks highest migration in a migrations directory and runs ‘yiic migrate to’ command.
I can support this:
I also use a versioning system - I use Subversion as I have not gotten the time yet to become familiar enough with GIT. The branching model proposed on the link in the previous post is a good one (there are important subtleties in the way it is done!);
I also use migrations, and I use them exclusively. To modify the database, I write a migration - I do not modify the database first. Beware that migrations do not (always) clear the schema cache. I haven’t determined a sure way to do so yet, but it is covered in the upgrade script.
I have the ability to test the functionnality on a test server.
I haven’t done as advanced as suggested to automatically downgrade migrations based on the revision, but it’s a nice pratice.
I fully scripted the upgrade procedure (but I still manually confirm the migrations):
svn update /var/www/public_html/<project>
svn update /var/www/public_html/yii
[size=2]chmod 777 /var/www/public_html/<project>/assets[/size]
chmod 777 /var/www/public_html/<project>/protected/runtime
chmod 777 /var/www/public_html/<project>/protected/runtime/*
/var/www/public_html/<project>/protected/yiic migrate
rm -rf /var/www/public_html/<project>/assets/*
# Touch the file of which the time is used in the asset hashing.
touch /var/www/public_html/<project>/protected/runtime/updateTimeReference
[size=2]wget -O /dev/null http://<server>/<project>/index.php?r=apcinfo/apc/clearUserCache[/size]
varnishadm -T 127.0.0.1:6082 url.purge .
So you can see the different steps:
[size=2]- Make sure that access rights are set corretly (SVN breaks them sometimes).[/size]
Perform migration.
Empty the assets folder.
-Touch the file used to determing the asset hash (my asset hash is based on the time of that file so that clients see a different URL for the assets to force a client side update);
Clear the APC cache (Here I get the web page to clear the cache, but I do it in a better way in my newer scripts); The database structure is also cached in there!
Clear the server cache (I have Varnish on the server for caching);
During the update a lot of assets will continue to be served from the server cache which is good.
I run that script on the test server which will usually show the things that are different between the development machines and the production server. Issues are mostly with the migrations.