We're developing a dynamic website that is to be hosted on Azure Websites. Before going to the staging phase, I'd like to test it locally in an environment that is as similar to the production environment as possible. (By testing I mean clicking around and checking that things work, nothing fancy.)
Right now we're doing this with standard Apache, MySQL and PHP installations, but I fear that things that work on this setup might not work on the live web server (Azure Websites).
Ideally, we'd use our own computers to run virtual machines that would be exactly like the production server we will be deploying to. Is this possible? If so, how? If not, is there another way that is better than what we're currently doing?
Your best bet will be to perform a test deployment to an Azure Website instance. There isn't a local emulator or replica for Azure Websites and Azure Websites are more than just a vanilla instance of IIS.
To provide you with the best chance of success I would recommend:
Replace Apache with IIS locally.
Ensure the version of PHP you are using aligns with a supported versions on Azure Websites. Deploy the PHP "runtime" on your IIS setup locally.
MySQL - again check supported versions align with the version you are running. This isn't embedded in the Azure Websites feature - you could run your own on a VM or leverage one from ClearDB.
Related
I do not understand fully how might the operating system have anything to do with something deployed on the web if you are not hosting the site locally.
Also, if I do not have a Linux machine, can I replace it by running WSL on my Windows PC? Or are there some fatal drawbacks that might point to not doing that?
No, you can develop PHP fine in Windows or MacOS.
You will have to install the right tools though like a webserver (Apache, Microsoft IIS, etc).
I good starting point is to use XAMPP.
PHP can be installed and run on Windows and MacOS as well as Linux and others - see https://www.php.net/manual/en/install.php for details.
Having said that, if you're planning to host the live site on a remote webserver which runs Linux, then developing that site on a machine which runs a similar operating system is likely to result in fewer unexpected compatibility issues when you deploy it to the live server. There are ways you can write the code in a cross-platform way (and 90+% of it isn't an issue anyway, there are just a few sticky areas mainly around files and paths etc), but there's always the danger of missing something.
If you prefer to develop mainly on Windows you could mitigate the above by having a virtual machine, or container, or by using WSL (Windows Subsystem for Linux), where you run tests against the site in a comparable environment to its live environment before deploying it to live. There are other resources already available such as this online which discuss the specifics of using PHP with WSL, if you want to pursue that.
No, you can do PHP development on any OS.
BTW I will suggest you to do learn linux in future.
I have created yii app locally. And now I wish to upload the same. I have brought the domain, but am bit confused, as which type of hosting should I go for ?
I have options like Cpanel(Linux), Parallels Plesk for Windows, VPS and Dedicated servers on some sites.
I have developed application using Yii 1.1
and database in MySql.
Could you guys suggest me best hosting available and suitable for me to go with.(Though It should be economic. :-p)
And what things should I consider, or are required while buying a hosting for my Yii application.
Edit :
I actually tried hostname/path/to/yii/requirements/index.php and It passed on my friends shared hosting, but I couldn't find proper way to install the Yii on his server space (He has an Windows hosting).
Someone said I'll require an SSH to run a command ( $php /yii/framework/yiic webapp directory-where-app-will-reside ) to install yii framework on server.
When called the Tech-support of his hosting agency they said youll have to go with VPS or dedicated server for SSH.
Yii applications runs on any servers/hosts that support php.
In this case you need a server or host that support mysql too.
Its related to your website traffic that choice sharing hosting or VPS.
In your application have to exists a file named requirement.php that shows Yii requirements, of course in Yii2. For Yii1:
Requirements ΒΆ After installing Yii, you may want to verify that your server satisfies Yii's requirements. You can do so by accessing
the requirement checker script via the following URL in a Web browser:
http://hostname/path/to/yii/requirements/index.php Yii requires PHP
5.1, so the server must have PHP 5.1 or above installed and available to the web server. Yii has been tested with Apache HTTP server on
Windows and Linux. It may also run on other Web servers and platforms,
provided PHP 5.1 is supported.
However is better your host be on LAMP platform.
I've got a Windows 7 machine upon which I do both PHP/MySql Dev, and .NET/C#/Sql Server coding. Due to a recent re-install, I thought it might be an ideal time to try and keep my machine a bit cleaner rather than install both Apache and IIS, etc.
I installed VirtualBox, with Ubuntu 10.04 as the guest OS, with the plan to move my PHP development from my old Windows/Apache/MySql platform onto this virtual image. In addition to this, I want to add CruiseControl/phpUnderControl to my PHP development process.
So far I've got Ubuntu 10.04 installed with a LAMP stack, plus Netbeans for PHP, MySQL Workbench, etc, which is effectively the same as my old Windows dev set up, but I've now also installed SVN and CruiseControl (I've not installed phpUnderControl yet, but that is the next step).
My question is, can I use this virtual image as both my "local" development environment and as a build server, so that I don't need to clutter my native windows machine with MySql/PHP related software (meaning I can keep it nice and clean for .NET development)?
I imagine I'd need the virtual webserver to be able to serve both a "local" dev version of any given project I'm working on, as well as a staging version, which would build using cruisecontrol/svn commits?
Or should I separate my dev and build servers, perhaps keep the local development in windows, and only use the virtual image for the build server? or perhaps have two separate virtual machines for different purposes?
I'd appreciate some advice on the best way to set this up. One of the projects I want to work on is quite complex so I want to make sure I get this up in the right way before I start the project, so that I can ensure the project is well maintained with versioning, unit tests and continuous integration, should I ever need to involve other developers on the project.
If you are looking to keep your Windows box clean of MySQL/PHP tools then I'd strongly recommend the two VM approach. One desktop linux distribution for development with LAMP etc on it for the quick code/debug turnaround and one that mirrors your real server install (with the addition of svn etc) for your test builds.
This gives you huge benefits for both having a nice dev environment and more importantly having a test server that will reflect operation of your code on the live server. This way you can keep your dev environment VM up to date with the latest updates for the distribution (kernel, tools, etc) and hold the build VM at whatever application versions are on the live machine. This takes a lot of the guesswork out of "is it the new version of library X or my code?".
If you want to go slightly overkill you'd actually want 3. One for dev, one for SVN/continuous integration and one that exactly mirrors your server so you can test deployment/system configuration.
If you are considering having your VM for dev why not set it up exactly as you would setup your staging/production environment?
Furthermore you can setup your VM to host the code repository, and the web server, and then connect your tools that are local to your host machine (Windows). That way you can develop on your Windows box, connected to the VM.
This gives you the ability to do everything in your local environment while simulating the server environment in your VM.
VirtualBox does networking really well too, and you should be able to make your Windows host connect via the network to the server as if it were really another node on the network.
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
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 !