I found this interesting post on the Xlinesoft forum tonight. (Best Practices) It relates to Best Practices for using PHPRunner & Subversioning.  I currently don’t have a use for this in anything I am working on but thought that it was pretty interesting so I decided to include it here…

——————————————————

1.0 Summary:

Setting up an SVN Repository significantly increases manageabilty of large scale projects using PHPRunner across many environment instances and developers. SVN Repository will also encourage companies to use PHPRunner to be used in larger scale projects. The output codes can be deployed based on the subversions and the config file can be determiend upon staging.

2.0 Case Statement

I have a project that is used in the development and live environment. Initially, it was not an issue since the db schema was synched. As the the dev version is release to production, and additional tables were added to the dev environment, I found it almost impossible to manage the project with my simplistic approach. What I ended up doing was for each instance of the development (dev, test, stage and live), I created seperate projects. so, I now have 4 individual projects. Our european counterpart saw our US project and of course, they requested for each of their instances which of course was about 6 all together. So, now I have a total of 10 seperate project for each db instance of our development phase. In my mind, the only difference is the config (i.e., host, user, password and db name).
For awhile, I would just select one of the projects, make my modifcations, and then save as for each instance of the project. This worked for awhile.

The problem started to occur when we went live the first time. There were enhancements that I wanted to make for the production version. Meanwhile, the db schema in the development and test instances started to change. So, I found many of my links started to break. So, I could no longer just simply Save As. The next step was to Cut and Paste.
I stopped Saving As, and started doing the following. I would make the changes in one of the most complete instance which usually was the development instance since its where the new tables are comming from. Then, I would open another PHPRunner and open one of the other instances that I wanted to update. Of course, I couldn’t update all since some of the test and stage instances have not been updated.

As a result, there was chaos in my codes. I no longer didn’t remember which project belonged to what instance. I didn’t know which one got updated and which ones are the same and which ones are broken. In other words, the project(s) became extremely unmanageable.

3.0 Analysis

This is a typical result when what seemed to be an easy process ended up entangled. Many times, the simpliest approach many not be the wisest approach and could cause havoc on project and resource management. The criteria for a simple project is if the proejct is being developed by a single develper on one or two instance of the same project. Both db instance must be synched for most of the time or at least a push to keep it in synched. As soon as a third unsycnronized db instance is introduced, then it can no longer be considered as a simple project management case. In order to avoid the pitfall of the case statement, one must ensure scalability, flexibility of code management, as well as the deploy process.

 

4.0 Approach

4.1 Set-up

The way to resolve the issue was we deployed a subversioning tool, SVN with a UI frontend, Tortoise. We created a project folder in the SVN Repository and a trunc.
I selected the best “version” from the projects, which we’ll call ProjectPHP. I then looked for the PHPR project file and copied that and the tmp and visual folders into my SVN trunc folder (which was also in my local apache htmdoc webserver path). I opened PHPRunner, make the changes I wanted and Save. I am now saving the PHPR file into my SVN trunc folder that is also within my apache webserver folder. I set my output file directly onto my trunc folder and I set the preview with the localhost url. I build the projects.

4.2 Work Process and Project Management

If all goes well, all the output files is created within the trunc folder. I use the preview just to see if anything was broken. When I am satisfied with the changes, I close PHPRunner and then go to the trunc folder. I delete the tmp and visual folder since I discovered that once I successfully build an output files with the tmp and visual folders, I can erase those two folders. Somehow, when I open PHPRunner and build it again, PHPRunner knows where to look for those tmp and visual folders. Also, for some reason even if I delete these folders, when I go to my Visual Editor, I can still see all the icons.

I committ all the files to the SVN Repository. (Note: It’s realy easy to do it using Tortoise SVN). I know have a trunc of my project. I then check out a Working Copy. This is a good idea since you don’t want to mess up your trunc version since it will always be your “base copy” of the code. In my working copy, I can open PHPRunner and open that particular project file. It works beautifully. All the icons show up in my visual editor. I can change the db configuration so that I am developing to the relevant instance of the database. Once I am done, I save my I used the Live instance of db to create or update the project. Once I was satisfied, I save my project which was the latest and greatest of the codes that I have been chaotically managing. Once we created the trunc, we created tags and branches.

I checked out the trunc into my Working Copy folder. For now, my WC is pointed towards the trunc. For every major milesone I reach, I create a Tag. The naming convention for the tag is usually the date and some task indicator like Dec102008_Task_1of3 or some other meaningful naming convention. I continue with my work on my WC until I complete all my tasks. By now, I have 3 tags, since I created them for each milestone.

I then committ my changes into the SVN Repository. Since I was pointed towards the trunc, it updated the Trunc. But since it is also a completion of a version of ProjectPHP, I created a Branch and called it Revision 1.0. This is my first “subversion.”

For now, I can continue to make small modificaitons or bug fixes to Revision 1.0. It is important to note that I am working constantly on my WC (Working Copy). Basically, I can “Switch” the WC to the trunc, tags or branches. When I am working on Revision 1.0, I will make tags along the way in order not to lose any of my codes in cases I mess up further along the way. There is a stopping point. Once I am done with my changes, I create a subversion Revision 1.1

Note: Please refer to the sources link below for more detailed subversion workflow.

4.3 Deployment

For every completed revision, I test it in the Test, QA, Stage environment. And once it passes all 3, then I deploy it to Production. We created a page that allowed me to selecte which subversion I want to deploy and the “dbcommon” version that I want to use. Since in PHPRunner, the db information is part of the editing the project, when it builds the file, it also builds the dbcommon that has all the db information (user, password, etc.). So, when there is a different db login for each instance, you will have to specify the correct “version” of the dbcommon. All I did was to create one dbcommon as a “trunc” and then created all versions of that for each instance of the db.

Whenever I deploy, I select the code that I wanted to put into dev, qa or stage, and select the appropriate dbcommon. It is a dropdown. The staging process basically takes all my files which are the output files and overrides the dbcommon with whatever “version” of the file I select. Remember the version is realy just to be able to have all the dbcommon for all the instances.

Also, there is one caveats for those that may want to have a others use the project for each of the instance. So, say if you have a Live version with the old db schema. So the Live version is Revision 1 and all the subversions. The active development is already on Revision 3, for example. And you’ve made some changes on Revision 3 and deployed it to your develpment and stage instances (and not Live of course, because the latest db has not been deployed to Live).

Since you still want to test and stage your Revision 1 code, you can deploy the codes to the development and test environments but use the db instance that has the matching schema (usually by now, it will be just the Live version). Notify the folks using the tool that you’ll be testing and staging a production fix and therefore need to log out. Once you verify in test and stage the codes, deploy the code to Live. At this point, unless there are major functionality and not just small fixes, you may have to merge it with either Revision 3 (the latest and greatest version of your project) or back to the Trunc.

I suggest not to do this however. I would just leave Revision 1 and all its subversions where it is. It is easier just to make sure that that functionality is copied over to Revision 3 and then merged back to the trunc (since Revision 4 may be under way).

5.0 Conclusion

When you use SVN with Tortoise and set up the appropriate subversions, your project with multiple developers and instances can be manageable, as long as everyone understands the subversioning principle. Keep the PHPR file with the output files and delete the tmp and visual folders once you have successfully built a project within the svn file folder. The PHPR file gets subversioned as well. In other words, it becomes protected for any accidental mistakes (like I have done so many times with my manual management of my php projects.)
I hope this post will encoruage to use PHPRunner at a large scale basis and will encourage the makers of PHPRunner to make it more and more robust.

6.0 To Do’s

• Set up URLs for each project intance (dev, test, stage, live). These corresponds to the db instances.
• Set up SVN repository
• Set up staging page. There will be a list of the environment where the codes will be deployed, a list of the code version to deploy, and the dbcommon version to override the dbcommon built along with the PHPRunner.
• Set up Project Folder then /trunc, /tags, /branches (Please see the link and study the manuals)

Resources Links:
SVN
Tortoise