Deployment "best practices"
Moderator: General Moderators
-
greyhound4334
- Forum Newbie
- Posts: 2
- Joined: Fri Sep 23, 2005 1:36 pm
Deployment "best practices"
Hi,
I hope this is in the right forum. Couldn't find one that really seemed exactly appropriate.
My question is how to learn about php application deployment "best practices". I've got a few nice little, and even somewhat sophisticated, apps running on my local network. I even "deploy" the apps to multiple servers. However I'm now taking the first steps towards writing and deploying apps for other people.
So, I now realize that some of my code inadvertently is dependent on my environment. Furthermore, I realize that I've "made up" the whole file structure architecture of my apps -- I have reasonably logical reasons for putting stuff in certain places, but this makes my problem even more complex. I now have several different kinds of runtime objects that I need to locate in different locations, and all of them need to be made "environment independent".
Let me give a specific example. I've coded some database libraries that I intend to use across several different apps. I deploy these libraries to a shared location, then use "require" statements to include them in my various apps.
Anyway, I know I can design solutions for these problems, but I figured that most professional developers must have run into the same issues, and there must be some "best practices" about how to set things up. I guess I'm asking things like:
- where do you locate such "shared libraries"?
- how do you make your code environment-independent (i.e., the same code that runs in your development and testing environments runs, unchanged, when deployed at a customer site)?
- what kind of deployment tools, if any, do you use to assist with this?
- is this covered in some classic php development literature somewhere?
Hope these questions make some sense and some of you can either offer suggestions, or offer pointers to where I can read up on this stuff (googling and looking in the usual places didn't seem to turn much up).
Thanks,
John
I hope this is in the right forum. Couldn't find one that really seemed exactly appropriate.
My question is how to learn about php application deployment "best practices". I've got a few nice little, and even somewhat sophisticated, apps running on my local network. I even "deploy" the apps to multiple servers. However I'm now taking the first steps towards writing and deploying apps for other people.
So, I now realize that some of my code inadvertently is dependent on my environment. Furthermore, I realize that I've "made up" the whole file structure architecture of my apps -- I have reasonably logical reasons for putting stuff in certain places, but this makes my problem even more complex. I now have several different kinds of runtime objects that I need to locate in different locations, and all of them need to be made "environment independent".
Let me give a specific example. I've coded some database libraries that I intend to use across several different apps. I deploy these libraries to a shared location, then use "require" statements to include them in my various apps.
Anyway, I know I can design solutions for these problems, but I figured that most professional developers must have run into the same issues, and there must be some "best practices" about how to set things up. I guess I'm asking things like:
- where do you locate such "shared libraries"?
- how do you make your code environment-independent (i.e., the same code that runs in your development and testing environments runs, unchanged, when deployed at a customer site)?
- what kind of deployment tools, if any, do you use to assist with this?
- is this covered in some classic php development literature somewhere?
Hope these questions make some sense and some of you can either offer suggestions, or offer pointers to where I can read up on this stuff (googling and looking in the usual places didn't seem to turn much up).
Thanks,
John
There are two ways you can include shared libraries (that I know of). One is to not make them shared at all - have a separate instance of your database class (for example) in each app. This'll be a pain when/if you upgrade that class, but you'd have to go to each client anyway.
- By default, php.ini describes a default include path. This is a path to a folder that PHP always checks first, when you call include('myfile.php'). It's a pretty safe bet to put any shared libraries into that directory, as it's an absolute path rather than a relative path.
- Long story short, there's no way to guarantee drag-and-drop functionality with an app unless you have complete control over where all component files go. It gets a bit easier if you require the client to do some configuring (via web or a config file).
How to make your code environment-independant? The first step is to not use any libraries that can't be included at run-time. If you're making PDF's for example, don't use PDFLib (which must be compiled in), use FPDF or EzPDF (which can be included like any other file).
- Also, make sure you don't use any functions that work differently on different platforms. No functions come to mind, but I know they exist.
- Finally, you need to be really conscious of the functions you do use. As PHP has grown, some functions have become deprecated, or the type/order of arguments they accept has changed. Writing something for PHP 4.3.10 might not work in PHP 3.8.
My deployment tools are command line scp, mysqldump and "Dear God...".
- By default, php.ini describes a default include path. This is a path to a folder that PHP always checks first, when you call include('myfile.php'). It's a pretty safe bet to put any shared libraries into that directory, as it's an absolute path rather than a relative path.
- Long story short, there's no way to guarantee drag-and-drop functionality with an app unless you have complete control over where all component files go. It gets a bit easier if you require the client to do some configuring (via web or a config file).
How to make your code environment-independant? The first step is to not use any libraries that can't be included at run-time. If you're making PDF's for example, don't use PDFLib (which must be compiled in), use FPDF or EzPDF (which can be included like any other file).
- Also, make sure you don't use any functions that work differently on different platforms. No functions come to mind, but I know they exist.
- Finally, you need to be really conscious of the functions you do use. As PHP has grown, some functions have become deprecated, or the type/order of arguments they accept has changed. Writing something for PHP 4.3.10 might not work in PHP 3.8.
My deployment tools are command line scp, mysqldump and "Dear God...".
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Re: Deployment "best practices"
I locate the shared libraries in DOCUMENT_ROOT/includes. $_SERVER['DOCUMENT_ROOT'] comes in handy for finding them from anywhere.greyhound4334 wrote:- where do you locate such "shared libraries"?
I use a lot of perl command line utilities to help me with these problems.greyhound4334 wrote:- how do you make your code environment-independent (i.e., the same code that runs in your development and testing environments runs, unchanged, when deployed at a customer site)?
- what kind of deployment tools, if any, do you use to assist with this?
I've solved that problem using a build utility and a common source code library. I find this method seems to accommodate multiple servers better for me too.pickle wrote:There are two ways you can include shared libraries (that I know of). One is to not make them shared at all - have a separate instance of your database class (for example) in each app. This'll be a pain when/if you upgrade that class, but you'd have to go to each client anyway.
-
greyhound4334
- Forum Newbie
- Posts: 2
- Joined: Fri Sep 23, 2005 1:36 pm
Thanks for the replies and suggestions. I'm still chewing on ideas, so I'll probably reply with further details and follow up questions later on.
But I guess I'm getting the impression that there are no generally available (gnu? open source?) utilities or documented best practices that deal specifically with these issues? Sounds like everyone's just worked out their own home-grown solution. Do the "professional" IDEs help with these issues at all?
-john
But I guess I'm getting the impression that there are no generally available (gnu? open source?) utilities or documented best practices that deal specifically with these issues? Sounds like everyone's just worked out their own home-grown solution. Do the "professional" IDEs help with these issues at all?
-john
The people at http://www.pearified.com/ seem to think different about that 
And if i'm not mistaken, they have started the discussion on the pear mailinglist again too if pear should include complete applications. It appears they don't want to do it because it would make pear unmanageable but i've noone seen that said pear1.4 wasn't up for the job
And if i'm not mistaken, they have started the discussion on the pear mailinglist again too if pear should include complete applications. It appears they don't want to do it because it would make pear unmanageable but i've noone seen that said pear1.4 wasn't up for the job
I use the php include path to locate common libraries. We develop code in the public_html/ directories of our development box. We use cvs for version control. I then checkout a copy from cvs into my home directory on the production server as a QA environment. I run all unit tests in QA. To move into production using an rsync command which follows the cvs ignore conventions.
Admitted that the pear site doesn't mention it (yet) But it is being discussed, thread starts here: http://news.php.net/php.pear.dev/39880.