Deployment "best practices"

Express the business side of your digital lives. Share your experiences and/or your comments regarding a business or organization.

No advertising.

Moderator: General Moderators

Post Reply
greyhound4334
Forum Newbie
Posts: 2
Joined: Fri Sep 23, 2005 1:36 pm

Deployment "best practices"

Post by greyhound4334 »

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
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Seems this would go best in the Enterprise board.. so moved. :)
User avatar
pickle
Briney Mod
Posts: 6445
Joined: Mon Jan 19, 2004 6:11 pm
Location: 53.01N x 112.48W
Contact:

Post by pickle »

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...".
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
User avatar
Buddha443556
Forum Regular
Posts: 873
Joined: Fri Mar 19, 2004 1:51 pm

Re: Deployment "best practices"

Post by Buddha443556 »

greyhound4334 wrote:- where do you locate such "shared libraries"?
I locate the shared libraries in DOCUMENT_ROOT/includes. $_SERVER['DOCUMENT_ROOT'] comes in handy for finding them from anywhere.
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 use a lot of perl command line utilities to help me with these problems.
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.
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.
greyhound4334
Forum Newbie
Posts: 2
Joined: Fri Sep 23, 2005 1:36 pm

Post by greyhound4334 »

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
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post by Weirdan »

After release of PEAR 1.4.0 it seems to be the way to go for shared libraries. Pear installer is not intended to install applications, though.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

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 :)
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Post by Weirdan »

I didn't say it's impossible to use pear installer this way, just that it's not intended to be used this way, according to what I red on pear site.
User avatar
sweatje
Forum Contributor
Posts: 277
Joined: Wed Jun 29, 2005 10:04 pm
Location: Iowa, USA

Post by sweatje »

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.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

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.
Post Reply