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.
Related
What I have so far:
Two VirtualBox LAMP machines (separate locations) where I connect my two Windows development machines via SFTP, to write code using PHPStorm.
One VPS machine where I deploy my code written for a project in Laravel.
What I am trying to achieve:
Fast and easy code deployment, as in: write the code in Windows via PHPStorm, test it on the LAMP machine, deploy to VPS if necessary.
The problem is that I need to use some php artisan commands on LAMP machines to get some code generated. This means that I always have to synchronize PHPStorm with LAMP files tree in order to see the changes. Then, I need to also sync the other dev (LAMP) machine and the other PHPStorm running on Windows machine number 2. I know that this can be done via Git.
So everytime I use the command line to generate code, I need to sync 4 machines (excluding the deployment server).
Later, if I add another pair of Windows/LAMP dev machines, the complexity grows.
Back in the days of Dreamweaver, I could write code directly on the deployment server. Not the greatest idea, but it was way much simpler and faster, and that's what I need now.
Any ideas on how can I simplify this?
Switching to WAMP so I can have files in sync with PHPStorm (because all is locally) is not OK because... Windows and PHP libraries issues :)
Also, switching to Dreamweaver is not OK either.
What other options do I have?
Thanks!
LE: on the side, I am also thinking if a NAS can be helpful for this type of problem.
LLE: is Linux Desktop + PHPStorm the only straight solution?
No matter the protocols
You can put your code outside of the guest machine and configure the guest machine to mount the code (mount a folder from the host inside the guest).
Apache will run slower because it will use the mounted remote-folder but PHPStorm will run at its maximum speed.
Taking protocols into consideration
Try using SSHFS on windows.
I use SSHFS for remote development from my Linux host machine to headless vagrant boxes (and/or to remote development servers / staging servers).
It's much faster than SAMBA (the windows SMB protocol) and oddly faster than NFS even though SSH uses encryption.
Coleages using Windows+SMB often leave their computers for 30 min while PHPStorm is indexing and git branch changes on the dev machine go unnoticed for minutes at a time.
Indexing over SSHFS usually takes less than 5 min on a Symfony2 project. Branch changes are detected in less than 15s.
Using Linux (shameless plug)
Linux is nice, and it's free, and it works out of the box (Ubuntu) -- including pesky USB-Modems which would normally require an install on windows.
You already know how to handle a Linux CLI the learning curve is already halfway crossed.
Auto-updates don't rule your life, they're not the king of you!
All the applications you need are part of the software repositories you don't need to look for anything, download 40+ executables and attempt to install them just to be welcomed by an error "invalid architecture", "windows version not supported", ".NET framework version too old", "DirectX version too new (wtf?)", "your cousin is a software pirate".
Dependency management is a concept Linux never fully solved -- but at least the bloody tried and in 90% of consumer use-cases it fits the bill. Windows is still eating glue at the back of the class.
How I solved the problem:
I have an extra Mac, on which I installed everything for my PHP ecosystem, including the IDE, so everything is local. That's the dev machine. Then I manually copy the code to the VPS when needed. Another solution was to install Ubuntu Desktop (or similar) on dual boot with Windows and use it as a local dev environment.
Much faster development / deployment :)
I would like to know how I can improve my development environment.
At the moment:
I'm using Netbeans as my IDE.
My local Dev server runs on a RHEL5 VirtualMachine similar to my production server.
My Netbeans project is editing the VM files via ssh (I have mounted the server as a local drive)
But:
It's slow
Files can disapear ( netbeans delete them ? )
I can't use git on it because it's slow.
The idea would be to be able to have a shared filesytem between the guest os and the host os.
Your setup sounds ok. You might need to give your virtual machine more resources however if your experiencing speed problems. That or move your server to a separate physical machine.
You may try a setup for files the other way around. Keep your files an the host machine in the shared folder. Than on your VM create a symbolic link from your htdocs folder to that shared folder. In this case developing should be very fast but only running the website on your VM might be slower.
EDIT: My setup is the following:
I got a XAMPP running on Windows 7 for development
I got a SVN repository on the webserver the production system is runnig
In a separate subdomain on my webserver I have a test system running
So basically I develop under Windows, I test on the same machine that runs my production system. We even got Macs for developing as well. I never had any issues developing under Windows and running the page on a openSUSE system (beside case-sensitive file names). Using the exact same machine for the test server is a good idea as it has the same limitations as the production server. So I think having three system DEVELOPMENT, TEST, PRODUCTION is the best you can get. But if it is only for some smaller projects your setup look quite good.
I find XAMPP sufficient for nearly all development locally :)
http://www.apachefriends.org/en/xampp.html
It depends on the type Virtual Machine you're running. For example Vmware is able to share a specific folder between the guest and the host OS
if you're using a mac, I'd recommend : http://www.mybringback.com/bringers/14509/git-local-and-shared-server-development-environment-with-ssh-setup/
which uses a local mamp/git/ and live server.
You could probably follow along with windows, but it's been awhile since I used it, so I'm 100%
best of luck
I get more and more trouble from running WAMP on my XP computer to solve my local development needs. It feels like as more and more things just go wrong or could not be installed at all to a Windows version of PHP.
I have been looking for an alternative and found AndLinux plus this link.
Would it be a good idea to get an Ubuntu box running virtually on my XP computer to simulate the production web server?
Yes, in case you don't want to use Linux as desktop OS running it virtually in a VM is quite practical. by using the VM's "shared folder" support you can use the same directory for local development using your Windows IDE and serving requests from the Web Server inside the VM.
In the past - ~5 ears ago or so - I used coLinux and wasn't too happy. On modern systems a small Linux VM just works well.
Regarding virtual machines:
Advantages
Isolation: Everything in the VM is completely separate from the host; no cross contamination.
Easy Testing: Most VM software have snapshot and rollback capabilities.
Mobility: If you wanted to, you could easily move the self-contained VM over to another machine.
Disadvantages
Inconvenient: File transfer between the host and guest. Using "shared folders" alleviates this somewhat.
Virtual Hardware: Not good for graphics-intensive programs or other software that relies on certain hardware features (which shouldn't be a problem in this case).
Generally speaking, the closer you can get to the production environment the better. Developing on Windows isn't wrong, per se, but you need to be able to test in an environment which matches production.
If you have the resources on your PC to do it in a VM, that will work just fine. If you don't, running it natively or using a remote server somewhere would also work.
Hope that helps!
Thanks,
Joe
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
We have various php projects developed on windows (xampp) that need to be deployed to a mix of linux/windows servers.
We've used capistrano in the past to deploy from windows to the linux servers, but recent changes in architecture and windows servers left the old config not working. The recipe works fine for the linux deployment, but setting up the windows servers has required more time than we have right now. Ideas for the Capistrano recipe are valid answers. obviously the windows/linux servers don't share users, so this complicates it a tad (for the capistrano assumption of same username/password everywhere).
Currently we're using svn-update for the windows servers, which i dislike, since it leaves all the svn files hanging on the production servers. (and we still have to manually svn-update them on windows) And manual updating of files using winscp and syncing the directories with their linux counterparts.
My question is, what tools/setup do you suggest to automatize this deployment scenario:
"Various php windows/linux developers deploying to 2+ mixed windows/linux machines"
(ps: we have no problems using linux tools or anything working through cygwin, we simply need to make deployment a simple one-step operation)
edit: Currently we can't work on a all-linux enviroment, we have to deploy to both linux and windows server. We can start the deploy from anywhere, but we'd prefer to be able to do it from either enviroment.
I use 4 different approaches depending on the client environment:
Capistrano and similar tools (effective, but complex)
rsync from + to Windows, Linux, Mac (simple, doesn't enforce discipline)
svn from + to Windows, Linux, Mac (simple, doesn't enforce discipline)
On-server scripts (run through the browser, complex)
There are some requirements that drive what you need:
How much discipline you want to enforce
If you need database (or configuration) migrations (up and/or down)
If you want a static "we're down" page
Who can do the update
Configuration differences between servers
I strongly suggest enforcing enough discipline to save you from yourself: deploy to a development server, allow for upward migrations and simple database restore, and limit who can update the live server to a small number of responsible admins (where the dev server is open to more developers). Also consider pushing via a cron job (to the development server), so there's a daily snapshot of your incremental changes.
Most of the time, I find that either svn or rsync setups are enough, with a few server-side scripts, especially when the admin set is limited to a few developers.
This will probably sound silly but... I used to have this kind of problem all the time until I decided in the end that if I'm always deploying on Linux, I ought really to at least try developing on Linux also. I did. It was pain free. I never went back.
Now. I am not suggesting this is for everyone. But, if you install VirtualBox you could run a Linux install as a local server on your windows box. Share a folder in the virtual machine and you can use all your known and trusted Windows software and techniques and have the piece of mind of knowing that everything is working well on its target platform.
Plus you'll be able to go back to Capistrano (a fine choice) for deployment.
Best of all, if you thought you knew Linux / Unix wait until you use it everyday on your desktop! Who knows you may even like it :)
Capistrano is the nicest deployment tool I've seen. Do the architecture changes make it impossible to fix the configs so it works again?
Why you can't use capistrano anymore?
Why you dislike svn-update?
What things in your app requires an special deployment ?
You can setup svn:ignore property on configuration files, so that svn update doesn't erase them, and then use svn export /target/path/ to get rid of .svn files in your Subversion repository.