Robert Cummings wrote:
On Thu, 2006-09-21 at 18:11 -0400, tedd wrote:
At 2:21 PM -0700 9/21/06, Chris W. Parker wrote:
Hello,
This is off topic but I wanted to get the list member's opinions on the
subject as it will probably benefit someone else.
-snip-
Is this a sound strategy or should I just realize that I can't publish
until all current features enhancements are completed?
Thanks,
Chris.
Chris:
I've been thinking about this as well. Please forgive my naiveness if
the gang already has a better way, but the method I used to do
application development was that I started with a folder that
contained all my code, which I named v1.0.
Whenever I reached a milestone of some type I thought significant, I
duplicated the entire working folder; renamed the duplicate the next
version (i.e., v1.01); and started working with the new folder. If I
screwed up, then I could always trash the new folder, duplicate the
previous version and start again. It was a system that worked for me.
At the end of the development cycle, I would have a long thread of
development versions. Often, I found that intermediate folders
provided branches for other development -- so, keeping intermediate
development versions was a plus.
Now, it's a bit different working with folders on the web because you
have one root (live) folder and making changes can be problematic.
However, there's enough similarity that I often follow the same
method as I used in application development.
For example, my current site http://sperling.com is alive and running
well. However, I am doing a complete rewrite of the site. As such I
duplicated the entire site and placed it in another directory,
namely: http://sperling.com/a -- and I work on that.
When I feel that revision is ready, I will save the current root
directory to my desktop, delete it on my server and then pull
everything out of my a directory and make it the new root. For me,
that would take just a few minutes. For more complex sites, where the
change must be instant, I would look into using the .htaccess file to
change the root index.
If there are better development schemes, I would like to hear about
them as well.
Use CVS or SubVersion already. I'm not familiar with SubVersion, though
from what I hear it's has all the features of CVS.
I would strongly recommend subversion over CVS. I've used CVS for many
years and can't believe how much better things are now I've switched to SVN.
I second Brad's recommendation of reading
http://subversion.red-bean.com/ - The Subversion Book. It makes for
excellent reading.
You can quite easily work on a trunk project, make multiple changes
and use it for general development work. (e.g. /trunk/myproject/)
When you are ready for your first deployment, you create a staging
branch (/branches/myproject/staging) using the svn cp command. You
then test this version in a simulated live environment. Other developers
can carry on working on /trunk/myproject while you work. If you need to
make any changes (e.g. bugs found during staging process), just commit
to the /branches/myproject/staging branch (don't worry we'll merge this
back to trunk in a bit).
Once you are happy, you are ready for the first deployment. Use svn cp
to create your deployment branch (e.g. /branches/myproject/deployed).
Also to keep a permanent record, you should tag this deployment (again
using svn cp to e.g. /tags/myproject/deployed-2006092201).
On your production environment, just check out
/branch/myproject/deployed (you could use the tag, but it will be more
complex when updating on next deployment (it would require using svn
switch rather than just svn up).
Now just merge any commits made to the staging brach back to trunk (use
svn merge). Now carry on development.
Now you're ready for deployment 2! This time the staging branch has
already been made so no need to use svn cp to create it. Just svn
merge all the changesets made to trunk since your last deployment.
Again test it and commit any required bugfixes. Then use svn merge to
apply all the changesets in the staging branch to the deployment branch
since you lasted deployed (it may just be one, but could be more if
there are bugfixes). Once you have commited these changes, make a new
tag with svn cp for your records (tags do not take up any real disk
space to don't worry about them even if your project is huge!)
On your production environment just run svn up.
Oh, don't forget to merge any bugfixes made to your staging branch back
to trunk!
If in an emergency you need to roll back, just issue an svn switch
REPO/tags/myproject/deployed-date of previous deployment and you're
back to how you were.
Hope this simple process helps - read the SVN book to get a better
understanding of the terms I've used.
Col.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
