When developing PHP applications, it's best to have a server you develop/test on, and then a live server you put everything once it's ready.
OK, but how?
If you are hosting through a hosting company how can you setup your own development server to test on that mimics all the LAMP settings as your live server? Because if they differ then testing on one that isn't identical to the live one, defeats the purpose right?
Is it better use another server through the same hosting company and ask them make both the development and live ones have the exact same settings?
Also what is the best work-flow to use to check files out from "live server" work on them in the "development server", then check them back into the live server?
Thanks!!
Two points from my daily work:
XAMPP is your one-stop shop for setting up a Apache/mySQL/PHP stack on Windows. I develop with it and deploy to Linux machines, no problem.
If you want to set up a Linux environment on a home server or virtual machine, I asked a question a while ago that may interest you: Pre-installed Linux for Web Developers?
Is it better use another server through the same hosting company and ask them make both the development and live ones have the exact same settings?
If you can afford a second server, it may well be the best way to go. On the other hand, a local machine you could upgrade and fiddle around with at will, and all that at a fraction of the long-term cost of a second rented server. If in doubt, I would go for a local machine.
Don't forget PHP is a very portable language. If you don't use any specific command-line tools or totally exotic extensions, making a PHP application work across Linuxes, and even on Windows is a question of some settings and details, but not really a big deal any more.
Also what is the best work-flow to use to check files out from "live server" work on them in the "development server", then check them back into the live server?
There are many, many opinions and practices in this field. For me personally, the following workflow has turned out to be ideal wherever I've used it - I am still in the process of implementing this myself in all projects and for all clients.
Edit files locally in IDE
Upload to development server via built-in FTP function of IDE
Test on development server
Once a feature is tested and works on the development server (i.e. it's "finished"), check the whole package into a Subversion (or other) repository
On the live server, have a build script check out the latest revision from the repository, download it to a directory with the revision number, and when finished, change a symbolic link that pointed to the previous revision to the latest one.
That way, every change you make to the live environment is logged in the version control system, and reverting to the previous revision is a question if seconds. To me, this was a huge relief compared to working with pure FTP everywhere.
Possibly also interesting question: Setting up a deployment / build / CI cycle for PHP projects
You can check all the production server's setup via phpinfo() and copy them on your development environment, no need for them to be on the same provider.
I usually commit the code to source control, and checkout in the production environment, hiding all the repository information via .htaccess, for example, see here.
Another (less recommended) option is to just have your master source in the development machine, and once it's ready FTP it up, there are various free tools that will only upload changed files.
As for the server side, you have multiple possibilities. You could use vHosts when you have Apache, with two different DocumentRoots: one for the live version, and one for development.
Or you can have the development environment on your local machine, and then the live (+ staging) on your dedicated server / webspace whatsoever.
In our current project we have a three-tier system:
development, staging and live. Staging and live are really almost the same, so that I can eliminate any problems when rolling out from dev to staging. It gives me another security layer before rolling out to live and eventually noticing that something went wrong.
Considering the workflow for rolling out, you should create an application config, where you can define several application environments (development and production) that automatically choose their environment based on URLs, defined environment variables or something else. So, in Zend Framework for example, this configuration driven behavior is built into your applications. In your config.ini file, you have a template which looks like this:
[production]
[staging : production]
[testing : production]
[development : production]
In there you can define different options for, lets say, your database connection i.e.
So when you check your changes on the dev machine into subversion and do a rollout onto your live system, you do not have to change the configuration. It should just work.
As far as workflow goes, that's typically what happens for small sites. Depending on the size of the project, though, it might be a good idea to use version control like Git or Subversion.
You don't need to go anywhere near as far as asking a hosting company to setup two identical hosting environments for you. The majority of the time they have up to date versions of php, mysql and apache. I develop on a Linux machine, that has a lamp stack setup already, so my workflow is pretty seamless, and I use a svn with post-commit hooks to upload to the live server.
If you are worried about incompatibilities between you're 'dev' server and the hosting server, the easiest thing to do is make a phpinfo file,
<?php phpinfo(); ?>
and check that your hosting server does not prohibit any special functions you use on your dev server (and this is pretty rare that the hosting company blocks vital things, and if they do you can easily send support an email and 99% of the time they will assist you in enabling whatever particulars you require. But as far as setting up your dev environment, I would go down the track of grabbing virtualbox, and installing ubuntu, find a tutorial for making ubuntu a web server (seriously only a few apt-get commands) and you will be smoking with gas !
Related
I have a VPS account on which I set up a Linux server to host some customer websites, and to upload "previews" of websites before publishing them to the production server.
I develop the websites on my own machine (Windows) and do most of the testing there. Because of the difference in platform, sometimes problems appear on the Linux host, and I could use a debugging interface on that...
My question is how safe is it to have xdebug on a remote public server which would also be used for hosting production websites? Is it possible? Recommended? What do you think?
Thanks...
xdebug is perfectly safe on a remote instance as long as you set the xdebug.remote_host variable. Otherwise it is a MAJOR secuirty problem because it would allow the attacker to view any variable in memory during runtime. It could be used to obtain your mysql login or any other secret variables you may have.
edit: A VPN is a good solution to keep leaking sensitive data over the net in plain text.
XDebug is possible, but not recommended on production, as it can slow your application. You should think the other way round and use linux as a development machine. If you can't (or don't want) to switch to Linux you can stay on Windows and use a virtual machine as a linux development server. If you do, try to be as close as you can as the production environment : same linux distribution, same version of php.
I work on linux and so does everyone in my firm, and the recommended solution in my firm is LXC, a very light virtualization solution. By light I mean it won't take ages to refresh your working tree in your IDE, because you don't have to mount the working tree on the host: the guest filesystem is a subtree of the host filesystem.
This way, I still can have an up-to-date fedora linux for my desktop, and develop on a debian with php 5.2 if I need to (and I need to). The thing is, when the virtual machine is configured for a given project, I can archive it and send it to a colleague that joins the project. This makes starting projects easier for newcomers.
i don't know how to say that in technical terms. and i think this is the reason to why i cant get good answer from Google.
i have xampp on my local winxp machine. i use it for developing websites locally then upload these files to my clients shared hosting accounts.
the problem that in 2 years i have always found differences between how xampp works and how the web server work.
some code work locally but dont remotely and the opposite. also flash behave differently on xampp than the remote web server.
is there is a way i can get the server configuration and use it with xampp like get the server php.ini and use it with xampp?
In fact XAMPP may behave different than your production system's web server.
This might be annoying at first, but it is definitely manageable.
Some thoughts:
Run
<?php
echo phpinfo();
?>
on both systems and check different features.
If a feature of PHP is marked as experimental, just drop it.
In case you need to deploy on different production servers, prepare a script called grabProperties.php and add code which checks essential properties you know to be in use. Output the result in some normalized way, so you may use another script to compare results and prepare a nice report.
Certain features activated in XAMPP are not enabled on most web hoster's server - e.g. Flash support. Before using these features, first ensure they are present on your production system.
You are always free to change php.ini. Thus, you may enable or disable modules in such a way, that you dev system mimics your production system's settings.
I wonder, that Flash problems relate to PHP itself. More likely, problems relate to erroneous code.
That said...
I do write PHP for quite some time. Upgraded XAMPP on dev and Apache/PHP/MySQL on production system several times. But not a single application failed to work after the upgrade.
Several times, I moved from dev Windows and production Linux to dev Mac OS X. Even there, everything worked fine immediately.
Needless to note, that not a single line of code needs to be changed between dev and prodution systems.
The essential point to to write high quality code is based on a defensive style.
Check as much input parameters of as much methods as possible (see assert()).
Log all errors to a log-file and visualize it using your admin backend (see set_error_handler()).
Use type-hints as often as possible (see type-hinting)
Set the maximum error level and code in such a way, that not a single warning appears.
Still unsatisfied?
In case you are still unsatisfied with XAMPP, prepare a virtual machine with VirtualBox, install some Linux edition and enable apache, mysql and php.
If your hoster's server is on linux - which is very likely - there should't be a big problem configuring the virtual LAMP server in a similar way.
We've been battling this problem for some time now, and can't seem to find a perfect solution that would satisfy all the requirements of making life easier for developers.
Right now we have the following setup:
Linux development server (as everything we produce runs on linux, and it uses some linux-specifix libraries)
Windows desktops (as the office network is on windows)
Every developer has a home folder on the dev server with a virtual host set up to run their code. This folder is shared using Samba.
Zend Studio IDE that is set up to use that location (as a network drive) to work on projects
Remote debugging to be able to run applications on the dev server and be able to step through the code
So the main problem we are having is that everything is slow...
Zend is slow to index the project, as it has quite a bit of files (including externals like full framework) that need to be transferred through SMB.
Remote debugging is slow, as Zend studio needs to fetch the file, then send it back to the server to run it (running "Local if available, else server"; otherwise breakpoints don't work)
Tortoise SVN is slow to get file status for the commit (command line remedies the problem, but it's much less user friendly, especially with more complicated things like conflict resolution while merging)
Branching out to any of the solutions that would have multiple server configurations brings up a problem that there is a chance of having different configurations everywhere, which will introduce additional layer of uncertainty and possibly bugs in production.
Development and debugging under windows is not possible because of linux dependencies in the code (like POSIX functions).
So how do organizations solve these problems? What kinds of set up are you using? What kinds of problems are you facing, and how to you resolve them?
One solution that works in some situations is to :
Have the code on your local disk, on the physical computer running windows
This code is the one you're modifying with your IDE
So, IDE is working as fast as possible : no SMB access for each file.
Also have the code on the Linux server
So Apache runs fast : the code is present on the server
Use some kind of synchronisation mecanism, to push every modification made on a file on the Windows machine to the Linux server, via the SMB share.
Using Eclipse, the FileSync plugin does a good job, over the SMB share.
WinSCP can also be used, to keep a remote and local folder synchronized, over an SSH connexion
Advantages :
All local operations are fast
All server operations are fast
Drawbacks :
You must always use the tool that ensures synchronisation (For instance, with FileSync, everything must be done in Eclipse -- and nothing in any other software)
Note : for SVN, no need to use Tortoise : there are plugins that integrate into Eclipse (Subversive, for example)
Not sure about debugging
Modifications done directly on the Linux machine might not (depending on the solution) get synchronized to the windows desktop.
Still, the best (fastest and most powerful) solution is generally to use only one computer -- that would run Linux, in your case, and not Windows.
Your tools will most likely work under Linux
If needed, you can install Windows in a Virtual Machine, for some software that don't run on Linux
It'll encourage everyone in your team to know Linux better ; which is always useful, when your production environment is not Windows ;-)
I recently launched a service, meaning I can no longer work directly on the site, or I do so at a risk.
I haven't been able to find any "standard" or "best" way to make a development server. The two things I have seen are
a) Using a GIT or SVN to host the data (this doesn't quite solve my problem, I need to be able to develop somewhere, preferably not my home computer)
b) Capistrano (for Rails, is there something for PHP?)
The current solution I'm looking at is putting a complete copy of the server on "development.domain.com", which would then allow me to work on everything, and I can simply copy the files over to the main section.
Is this a workable solution? What's the optimal solution? (Separate server, special tools, etc.)
EDIT
This system be developed by a number of developers. The server settings have been tweaked considerably to allow for the full functionality and security of the system. Having the development on my own computer is not a workable solution, nor on an intranet type of system as none of our programmers are in the same location.
I'm looking for an on-a-server solution.
Three suggestions:
1) You are on the right track with making sure that your source code is in some form of source control (git and svn are both excellent choices). This should be priority #1.
2) Have EVERYTHING that has deviated from a standard configuration be in some form of source control. This means your apache configs, your php.ini, database configs, etc. Then when you setup your staging and dev servers you can be (relatively) assured that everything is the same across all of your servers, otherwise you are just guessing.
3) Look into some sort of build scripts, either ant, phing, or anything that you can use to reliable build your environment from scratch on any machine.
There are tons of other things you can do, but if you implement these three you'll be well on your way to having the ability to easily setup a dev/staging server. This will also give you the added benefit of ensuring that all of your developers have a similar environment when doing their development as well.
http://www.wampserver.com/ for windows
or
www.mamp.info for mac
or
load up a VM
Personally, I do my programming on a mac, running VMWare with suse or redhat for the server test environment. I've used mamp in the past and it works well; but sometimes I like to work in a real operating system.
That, or setup a physical test server. PHP / (choice of DB) now adays runs on anything (mac, windows, linux)
Depending on what how you want to do it, you could install VMWare right on the production server and dev in there; that is, if you run the server yourself. If your collocated or on shared hosting, you probably can't do that.
-Mario
Your development, staging, and production environments should be exactly the same otherwise you risk the change of something bombing as you move between environments. Obviously your development environment will have development settings (e.g. PHP's display_errors on, possibly a remote debugger, etc) but otherwise they should be as identical as possible.
As everyone else has mentioned if you aren't using version control you as asking for trouble. Not only is this a good practice for development but also eases deployment between your different environments. This is especially true when there are multiple developers working on a project.
I started to use a git repository as starting point. Main development is done on my local mac. At a certain point I push the changes and pull them on a development server where further testing is done. If everything is fine, I pull things on the development server. This is more or less the way, capistrano works, I think. I wrote a central script for these tasks, so I can update development or production servers with a single comand.
In several years I am using my workstation as development environment. I think that most of web developers use their workstation for running their servers, Apache, Tomcat, Mongrel etc. I have been working in a company that have a Unix development server in another city, with the document root folder share with samba. I am still developing on my Windows PC because to use IDE like Eclipse PDT and RubyMine requires a fast access to the file system and because I want to try things on my own without bothering with helpdesk tickets and stuff like that. I prefer to run my tools, install/uninstall software easily.
The main problem is that I am forced to use Windows and I cannot develop on a simialr environment to Unix. For instance on production we have Passenger, in Windows Passenger cannot be used and since I have a shared environment, PHP/Rails, in development I have Rails URLs with http://localhost:3000/ and for PHP just http://localhost, on the production I just have http://domain.com/apps for Rails and http://domain.com/
So do you run your developemnt server in your workstation or on a remote server?
I would like to have a confirmation that my practice is the most adopted. Thanks.
A VM on my workstation (which has the advantage that it goes anywhere my workstation goes and I don't need to worry about bandwidth when I'm at a remote site)
I develop on my workstation, then generally publish to a staging server that mimics the live server for testing prior to publishing on the live site. When there is no staging server, that step is omitted.
I work on Linux, so don't have the problem as my servers are a mixture of RedHat, Centos and Ubuntu.
You could create a virtual machine on your machine, e.g. with VMWare of VirtualBox, that mimics your remote server. That way you'd have a non-Windows environment locally to develop on.
I do the same, I have a development server locally to have immediate access to any changes made. Whenever I can, I build a staging process on the production web server as well for the thorough testing.
If you are interested in running a Linux webserver locally (either in a box or a VM), check out this question: Pre-installed Linux for Web Developers?
I develop on a Windows machine, with Apache. When I'm happy with my changes, I push them to a test server (FreeBSD, Apache) for the client's feedback, and then when they're happy, push the changes to the production server (Debian, Apache).
Other than funny stuff like case sensitivity differences between the OSes (table names in MySQL, in particular), I haven't had any platform-based troubles.
Pretty much the only trouble I had was the initial setup, figuring out which PHP modules I needed to install on my test server. My production server's setup's out of my control.
My rule is: work locally and integrate continuously.
But TBH It really depends on the project I'm working on and on the dev environment.
In general I'd rather having the whole environment on my box for many reasons:
I'm able to reproduce integration
I'm able to reproduce issues
I can work from home or without network
BTW There were projects in which I couldn't have it on my box just because the database was so huge, or the authentication system was built by another department and I could build / deploy it on my own...
I like coding on my laptop. Since I am only web developing I like being able to be portable and code from lots of different locations because I am travelling.
Being able to then do git push or svn checkouts means that I can sync any changes with my main repository and then ensure that my main development platform on a server in the datacenter is pretty quickly up to date.
If I wasn't moving around all the time, I would use my workstation for sure.
The answer depends a lot if you're working alone or on team, and the method used to share and transfer files (Subversion, Git, SMB, FTP, ...)
In the past we used to have a shared local developement server (Debian/apache), access files via windows shares (samba), and publication to remote (pre)production servers with FTP. But, that was dreamweaver time and we had a lot of issues working together on same project. The worst case was sharing work with remote teams, painfull version management accross FTP clients.
Now, we tend to use apache on windows (wampserver) ans SVN to share and publish files. It appear to complexify the thing when working alone, but for teamwork it has no comparison with the old way of working.
The issues with php/mysql on windows are known :
- less stability and responsiveness
- Paths must be written unix-way to avoid troubles switching to linux servers (C:/dir/file.php instead of C:\dir\file.php)
- You must pay attention to mysql table names and filenames case, because if an error in case happens it won't throw an error on windows. You get the slap when you switch to production server
- Command line tools / Apache or PHP extensions that are inexistant in windows world
We work sometimes with people using Macs ou linux workstation to get rid of theses problems.
If your developement process requires Passenger on the developement station, I think you'd better use a linux workstation or run a lightweight apache server inside a VM.
For us its all SVN. A branch for developer version, where all the developers are supposed to check in the files before they leave for the day. A branch for build version, the final running or buildable or deployable one will be located here. Then there is the stage system that is used for testing and demo. The copy on the stage will always be from the build branch.
Locally. Fortunately Visual Studio makes this pretty simple.
When I get to a state I am comfortable with, I publish to a beta server, then if we like it there in testing it pushes live.
Ken