situation
We our little company with 3 people, each has a localhost webserver and most projects (previous and current) are on one PC network shared disk. We have virtual server, where some of our clients' sites and our site.
Our standard workflow is:
Coder PC → Programmer localhost → dev domain (client.company.com)
↓
live version (client.com)
It often happens, that there are two or three guys working on same projects at the same time - one is on dev version, two are on localhost.
When finished, we try to synchronize the files on dev version and ideally not to mess (thanks ILMV:]) up any files, which **knock knock* * doesn't happen often.
And then one of us deploys dev version on live webserver.
question
we are looking for a way to simplify this workflow while updating websites - ideally some sort of diff uploader or VCS probably (Git/SVN/VCS/...), but we are not completely sure where to begin or what way would be ideal, therefore I ask you, fellow stackoverflowers for your experience with website / application deployment and recommended workflow.
We probably will also need to use Mac in process, so if it won't be a problem, that would be even better.
Thank you
Edit: One of the crucial parts is moving website from dev to live after any working update.
Edit: I will check MaxVt's answer if no other will appear :)
It is an involved question, but generally there are three major improvements you need to make to improve your processes.
Use version control
If projects are on a shared disk, I assume there's just a folder with the current state of each project. It is easy for developers to overwrite each other's changes, there's no history, and you can't be sure if a project is in a consistent state or something is currently broken.
Choose a version system and start using it. It's less important which one (of free ones - SVN is OK and more "centralized", git or mercurial are great and allow greater flexibility), but it's more important that any change, no matter how small, always goes through the version control.
Simplify promotion, deployment and rollback
There is probably a sequence of steps needed now to move from localhost to dev, and from dev to production - synchronize files, restore the database to a known state, configure server-specific settings... There may be a document describing what needs to be done, or it could be tribal knowledge. Your goal should be to begin simplifying and automating that, achieving a single command or script to do all the work needed to synchronize a server (local, dev or production) to a revision of a project in your source control.
By automating deployment, you can be sure all necessary actions are done in proper order, and you will not have mistakes in deployment that can happen even when all files are correct but some configuration or command was not run, breaking the site.
Introduce testing
How do you know that the revision you've just deployed not only compiles properly, but works as expected? For each non-trivial project, you should have tests to verify the most important functionality (login, adding stuff, producing reports, etc.) to make sure that the changes made by developers left the site operating properly.
There are testing frameworks specifically for testing web apps (Selenium comes to mind). Study them and apply them. Ideally this testing suite would be run as part of the one-liner deployment script.
Once you have done those, you've come a long way to having an orderly, predictable, and resilient development process. Your clients and your developers will thank you for that :)
Related
I've been trying to learn more about PHP and more server-side code in general, and I hit a point where I realized that if I want to upgrade my website, I would need to take it down and copy the code while the users were online.
Furthermore, since I haven't launched my website yet, and unindexed by Google, it rarely gets any visits, so I'm free to upload and test out whatever I want using PHPStorm + FTP. But I realize that once I finish my project, and have users, I wouldn't want to change things while they were using them.
How do people write code and debug, and setup before deployment to verify that their website would function fine? Also, how would you copy over the code? Both from a large website (i.e. apple.com, cnn.com - websites that need to be on 24/7) vs. smaller blogs/websites.
You're asking about Continuous Integration / Continuous Deployment ('CI/CD').
Basically you'll want to make use of a testing server to test your code on before the public get to see it. You deploy out your code to this server and test it thoroughly, confirming that everything is ready to go out to production. With more in-depth setups this testing can be automated with tools like Selenium or TestComplete.
In theory, you should be deploying a 'release cut' of a GitFlow workflow out to your testing environment. This ensures that all planned changes have been finalised and are ready to ultimately be shipped out to the public without any other changes getting mixed up in the release.
When you're finally ready to ship out to production, you'll want to plan the release, and meet with any associated parties. I'd recommend a proper release checklist, where you confirm that all of the additional features are working as expected, and that you're not accidentally removing any existing functionality (regression testing).
Note that a deployment out to production should have absolutely no differences to a deployment out to a test environment; the only thing that should be changing on the production environment is the server in which the environment is hosted, along with database configurations. This ensures that you're not accidentally testing / using any data that your customers might also interact with.
The production deployment itself should (essentially) just be a 'copy-paste' of the files to disk, and is often done with a Continuous Integration tool like Jenkins or TeamCity. Assuming you only have a small website, this should be an almost instantaneous procedure, and shouldn't even require any downtime on your production environment. If the process is likely to take a while longer (such as with a complex deployment), you may want to implement a maintenance page. This will inform your users that you're working on the website, and let them know when they can expect functionality to resume.
I'm a developer for an e-commerce website, when we were smaller (50-75 users online at a time) I would just use FTP eg, FileZilla to update the files I had changed with my latest edit, this would mean people would be served my changes and the website would not go down at all. For small edits, I would also just ssh in and manually edit the file if it needed to be done quickly.
Now we have grown much larger and have other developers (100-200 users at a time) to be fair I should be doing it this way before but I deploy directly from PHP storm/version control. I have working branches and once my work is ready to be deployed ill put it into the master branch.
Once the master branch has work pushed into it I have a script that checks for changes and clones the repo. (this happens automaticaly.)
There is a lot to cover here, and some of it is opinion based (which I will try to avoid).
How do people write code and debug, and setup before deployment to verify that their website would function fine
There are many ways to create a local development site, but most modern approaches involve containers. Docker is the most popular, which allows you to create replicas of a web server, database, etc. and run them locally on your machine. You can also use virtual machines to create a replica of your production server, or simply install the needed packages (i.e. php, apache, mysql) on your local machine.
Larger companies will typically have a QA (Quality Assurance) department who test all changes before they are deployed. As others have mentioned, some of this can be automated with testing software. When there is a QA team, you have a staging server where changes are first deployed. Once the changes pass QA and any automated tests (i.e. PHPUnit) they are deployed to production.
Also, how would you copy over the code?
This can get very opinionated, so I will just give you different options and not argue for or against any of them:
Use a service like rsync to transfer the files. With this approach, you typically have a staging server where you checkout your code from version control (or manually copy it if you aren't using version control), run any build scripts such as composer, gulp, etc., and then sync the files to production. In a larger setup, you wrap all of this into a script to automate it.
If you are using version control (let's use Git as an example), you can also pull the code down to your production server (as apposed to pushing it up to production), by running git pull on your production server. This will get all the latest changes, then you run any build scripts such as composer, gulp, etc.
There are also tools for continue integration (i.e. Jenkins) that facilitate a lot of the work mentioned above. You can go as far as setting up hooks on GitHub, so your code is automatically built and deployed when you merge into master.
On a small or personal project, it might be simpler to just use FTP and manually transfer the files.
I would like to have some input on how a professional development setup with the following requirements might look like.
several PHP-developers (say PHP)
each developer belongs to one group
each group has one team-leader who delegates tasks
each developer works on one Windows 7 machine
and developes either with NetBeans or Eclipse
each developer 'owns' one virtual test-server where he can run the code
the VCS in use is SVN
there is a staging server where the product is ultimately tested before it gets released/deployed
I gave some specific technology to not be too abstract and b/c I also would be interested in concrete suggestions for plug-ins etc.
There are several questions coming to my mind in that setup.
1) So every developer will work on
personal branch.
2) This branch is checked out in a working copy.
Now ... this working copy is edited locally on the PC with the dev's IDE and executed/tested on the server.
What would be in that case the best/usual way to do that? I mean - how do you get your edited code on the server without causing too much overhead?
Would the dev have the code on his local disk at all? Or would it be better to have the IDE write on the remote virtual server through a tunnel or via a specific protocol?
3) Every day a dev will commit his work into his personal branch which resides in a central repository.
Is there a best practice on where the repository is supposed to be located? A seperate server?
4) Then after a dev finished his task either s/he or the team-leader merges the new code into the respective main-branch or trunk.
The most confusing part is about what I wrote between 2) and 3). Because so far I only worked with a local server. For example a VM with a server running a code which is located in a shared folder so I will be able to edit it directly. I'm not sure how to bridge the gap efficiently when the server is now actually remote. Efficiently means not having to upload manually via FTP for example.
Also external sources or book recommendations are welcome.
edit
My question/s is/are aiming at a quasi-standard / best-practice. I think this is pretty much a standard development scenario so there must be a 'usual' solution.
edit 2
Okay ... so lets try with a picture:
V is the virtual test-server for one or more developers D. C and C' are the two code-versions. They should be kept as identical as possible.
Two solutions come to my mind:
1 : Edit C, then upload it to C', then execute C', then commit C.
2 : No C existant. Just C' which is edited through some tunnel technology and executed and committed.
My guts tell me both solutions are semi-optimal. So what would be "professional" / most efficient / fastest / most convenient / most friction-less / least error-prone / best practice / industry standard?
Any questions?
Maybe its not of great help but GIT sounds like a perfect fit to your problems, i recommend to take a look to the GIT features. And if you got time check Linus Torvalds him self talking ablout GIT. http://www.youtube.com/watch?v=4XpnKHJAok8
The standard procedure as you describe is more or less the same. I also you this approach for my team. It can also be called staged application development.
Here is how I am doing it, I use a remote SVN host (ex: assembla.com, unfuddle.com) to store all my codes. My team members store the information there on these remote svn servers. You can also buy an VPS and setup SVN there and user the same approach.
Best practices is to test locally and commit and commit as many times as you can but every commit must solve a problem or include a significant segment that adds any new feature.
Once the commit is done by everyone the lead developer then can login to the staging server via SSH using tools like PuTTY. First time the lead developer has to checkout the code into the folder where the codes are to be located. During this phase file conflict may arise if multiple developers edits same segment of a file. The lead developer should then resolve the code first and then proceed with the checkout. Once checked out, there onwards the lead developer will only need to do a svn update on the staging server to make the code up to date.
Basic idea is to get the code working on local setup then commit and update the staging for testing the application on a simulated scenario and then commit it to the live site.
There are a lot of if's and but's here which will need me to write a chapter on :) but in short this is the zest.
Tools (you can use to work under this setup):
- Tortoise SVN Manager
- PuTTy
- NetBeans
hope it helps :)
I don't like working with personal branches. I worked with ClearCase for almost 15 years and even though ClearCase probably handles personal branching better than most, it was still a big pain. Even worse, personal branches encourages people to not commit their work until the last minute -- usually a day or two before a major release.
For that reason, and to force developers to stay on track with each other, I highly recommend everyone working together on a single branch (or on the trunk) as much as possible. I keep telling developers to take small bites when they make changes.
What you sound like you need is a way to automate the deployment. That is, I make changes on my local machine, and with a single command, I make sure that the server has a duplicate copy of the code. You also want the deployment to be efficient. If you change a single 2 kilobyte file of a 2 gigabyte, 10,000 file deployment, you only want to copy over that one file, not 10,000 gigabytes. For that, I would recommend you write a deployment script in Ant.
Your developers can modify files, then deploy those files via an Ant script. The developers don't have to remember what files they had updated because Ant will automatically handle that. In fact, Ant can even modify files to make sure they contain the right environment information as they get copied over. And, of course, Ant can rearrange the files if the setup on the server is different from the setup in the source repository. And both Netbeans and Eclipse can execute Ant scripts right in the IDE.
So:
Have your developers modify code on their local machine.
Run an Ant script to make sure the server and the local machine are in sync.
Test on the server.
Then, check in their changes once they're happy with the results on the server.
Someone mentioned a Continuous Build System like Jenkins. That actually would be a good idea anyway even though it doesn't solve this particular issue. Jenkins could have its own server and database. Then when you commit your code, Jenkins would update the server and run automated tests. Jenkins can then create a report. It all gets displayed on Jenkin's webpage. Plus, you can archive your deployments on Jenkins, so if you tell someone to test "Build #20", they can simply pull it off of Jenkins where its easy to find.
I'm sure everyone has different ways of doing things but here are my thoughts.
"Best Practice" is probably "Continous Integration" ie each developer doesn't have their own branch but checks in to a common development branch. This forces them to handle conflicts and coordinate with each other early and often to avoid the lead developer from managing a huge train wreck merge later down the road. Take a look at cruisecontrol if you really want to go that route.
The best way is if they have a local apache web server and full php stack. You can use the Zend_Server community edition to get up and running on windows fast. Most standard php code will run just fine on both Windows and Linux, but if you are doing lots of file manipulation or cron job or cli stuff, or need memecache, etc you'll run into incompatabilities. If thats the case and the Linux only stuff is going to bite you use VMWARE or VirtualBox to run local linux instances and install the IDE inside those and just make sure they have goobs of RAM to deal with it.
Each developer needs to run a syncronize inside of Eclipse, basically an svn update, deal with any conflicts with the other developers right then and there, do local testing and commit their changes.
I setup a post_commit hook on the svn server that calls and /autobuild.php on my web server. autobuild.php runs svn update and gets the latest code changes as well as does any chown or chmod file permissions stuff and resets any server specific config files config.php. Its a little tricky to get it setup so that the apache user can run svn update, but once you do your beta/testing server always has the latest committed code. CruseControl, and several others can also help you do this sort of thing and add unit testing, etc
Now your Lead Developer still has a job to do merging the Development Branch into the Production One, testing on the dev server, and reviewing the commits of the others and deciding how and when to push out a release, but your not putting the burden on him of resolving every conflict and merging every change.
Your developers are not ftping files or ssh remoting into servers, they just work locally in their IDE and interact with each other through svn (and email, phone, chat, etc) updating to get the new code and commiting as they finish things.
I don't see any good coming out of having a seperate branch for each developer using SVN. Merging those branches might work in Git but with SVN your lead developer will be hating life very quickly with that type of setup.
Unfortunately, I've never had a senior developper or mentor to show me some of the best practices. So I develop sites (php/mysql) on my Windows machine with WAMP, I test in hidden (password restricted) folders on the production server and finally move sites to production folder.
I would like to have a more fluid/practical/error-proof setup so that from development > test > production, there is no hiccups.
The important points/questions are (you probably can come up with a lot more):
Ease of use
Easy to dev/test modifications after site is live (to avoid tests on production site)
No server difference between local/test/prod (error reporting, apache setting, etc)
Avoid problem with DB differences (ex: if columns were added, how do you add them to prod DB.?)
Do you skip the test environment or do dev AND test on the same.?
etc...
How do you guys develop PHP/MySQL websites.?
Do you use SVN.? Do you use IDEs.? Do you use VMs.?
Thanks.
This is a kind of frequent question - this is why most seasoned devs do not reply on - and generally end up in a flame war with torrid opinions. So, be careful about that.
But you seem to be an nice guy intending to get on the right paths, seeking for some really productive paths. And I recognize a little about myself on this a few years ago.
OK, first thing to keep in mind is: do not blind follow anyone on anything. Anyone can claim to be a great master, but you can find at least 10.000 guys far way better and completely anonymous. So, for anything you hear about do the following: listen, test, and take your own conclusions. If there is just one golden rule this is it. Everything else is crappy until your own conclusions appear. You are your final judge.
That said, let me begin for the one of the most current question: IDE. What you should use? You should use the one you can produce more and makes you more comfortable. Netbeans, Eclipse, VIM, Notepad++, Notepad, gedit, kate, quanta plus.... You have many options, and each person has it's own opinion. Test what you think interesting and go ahead with the one you choose.
This is true also for any methodology, framework or tool. Use, learn, and get critic about it. Stick with the one which makes you more comfortable and productive.
Same thing for developing environment. Does not matter that much if you develop on Windows, Mac or Linux. The important is get the resources you need available. The resources you need can and generally do change from one project to another.
So the best environment to develop a certain project is one that reflects the real environment where the production will run. What if you develop with PHP 5.3 OOP resources and at the end you get on a PHP 5.1? That's the point. The final environment is who tells you what is the best environment to develop, not the inverse.
For testing, you should trace a strategy. I'm talking about that as a 5 years Test Team Lead inside IBM. This because there are a LOT of testing you can perform, but not all can be really interesting to the current project.
First decide, according to project needs, what you are going to test. Security, performance, UI display, UI effects, error handlings, load and balance, usability, accessibility...
Take notes of what you are going to test (what, when, where, success criteria), and make a report of success and failures.
As I said before, the project needs is what guides you on every step. Testing is not different. If you just need to check the display on different browsers, feel free to use different machines, or VM's.
Generally this is sufficient. But if the project requires performance or load testing, then you will need specific load testing softwares. I will not get deep in this subject as it is very extensive.
It takes some time to find a ideal process and tools match, and after achieve that, you will always discover a new tool to test or a process to make you save a little time. This is IT.
Here's my recommendations:
have a dev environment purely for development. keep a staging and/or a live environment based on the resources you have at your disposal. the staging environment is where you test and ensure there are no serious issue(s) with your application. the live environment is basically your production setup. in fact, the staging and live should ALWAYS be the same. It is useful to reproduce issue(s) on the staging and do a bit of troubleshooting without modifying the code. Bear in mind, this also holds true for any associated databases.
Use SVN or some form of version control. This way you will have the ability to fall back to any stable version of the application if someday the world falls apart!
If you are using Linux environments you can write simple scripts to synchronize the setup with your latest (STABLE) development environment. Ideally, you do your development and conduct unit tests to ensure everything works as per design. Run a script and the staging environment is updated with the latest codebase. Conduct functional tests on staging and ensure that everything works as per specs. Run another script and your latest changes are moved into live/production environment.
My development process is still a bit rough, and I am looking forward to the answers also.
What I do for large projects is setup a git repo on my linux desktop and my windows desktop. I will test locally if possible. As components as finishinged I will push my changes to the centrally hosted git repo (private git hub account usually), or pull them to dev (i setup dev as a repo and pull from ssh). All MySQL updates are stored in update files, and I use netbeans for development (although I have used eclipse and others, netbeans just works for me).
I think you hit on all the important points. Personally, I
run the same OS and server software on the production server and my development system. Same versions of PHP, Python, MySQL, Django, etc.
I don't change DB structure often. I set up the DB tables on the dev. system, then use mysqldump to produce the table creation SQL. I install it on the sever using mysql <name_of_sql.file. When I do make changes, I back up the DB and then just do it through the command line interface. For PHP, I use Doctrine just for the table structure/migration support.
I write everything in Kate (Linux), Komodo Editor(Mac), or Notepad++ (Windows). I don't like IDEs very much, I much prefer to-the-point text editors.
I upload files to a staging dir, and check them with diff before copying them to the actual location.
This isn't the most sophisticated set up, but it's worked quite well for me. I'm the only dev working on the projects I'm involved with, which probably explains a lot. The most important part, that isn't really just personal preference, is the first one - match your dev/test system as closely to the production system as possible, including the OS.
I am currently in the process of learning the CodeIgniter PHP framework. At the current moment, I am looking to have a DEV environment and a PRODUCTION environment. Coming from a purely C and JAVA background, I am used to having everything locally (with version control), but since I will have the PRODUCTION side on a website, I was wondering a couple of different things:
Is it better to keep the DEV environment locally?
What would be a good (and easy) way when making changes on the DEV side to get them up to the PRODUCTION side (assuming the DEV env is local)?
Is it possible (and if so, how?) to setup CodeIgniter to have a DEV & PROD environment in the same codespace (say on the server but with different databases tables)?
When using Version Control on an application I would create in the Framework, is it recommended to only have the files I create for my application, or add the whole Framework (to keep the code consistent with version of the Framework)?
I appreciate any thoughts or suggestions you have in advance.
Thanks!
I don't use CodeIgniter, so I may not be able to answer all your questions ; but, still, here a few pointers :
Development environment : I like when each developper has it's own environment ; and it's generally easier / faster when it's on his machine
still, if your development machines are running windows, and you production server will be running Linux, it could bring some problems (there are a few differences between those two, like case-sensitivity in files names)
in this case, provided you have a powerful enough computer, using VMWare or VirtualBox to run a minimalist Virtual Machine (with Linux+Apache+PHP+MySQL on it ; the code source is on it too, exported via a samba share) might be a good solution -- that's what I've been doing few more than half a year, and it works pretty well
Pushing changes from dev to prod :
one solution is to log on the production server and do an "svn update" ; but I don't really like that (if some files have been modified directly on the production server -- yes, this sometimes happens), you may encounter conflicts and the like ; and that's definitly not fun at all, as it may break the site ^^
one solutioon I like more (takes more time to deploy, but if you deploy only, say, once a week, it's quite OK -- and definitly more secure) is to use "svn export" on one of the dev machines, create a tar/zip/whatever archive, and upload it to the prod server. Then, you extract it to a NEW directory ; and when it's done, you change a symbolic link to point your root directory to that new directory. Nice thing is : you keep the old sources on the production server, and if there's a catastrophic problem with what you deployed, you just have one symbolic link to change back to revert to the previous version -- and that can sometime save the day ^^
oh, and, as a sidenote : you should write a script to do that automatically for you : it will avoid messing with ine step one day, when doing it manually (and will help for the day when the guy that always does that is in holidays ^^ )
About using one instance of the sources for both environments : even if you plan on doing this only for the framework, I wouldn't recommend it :
it means having dev and prod on the same machine, which is bad : what if some still in development script becomes mad and does bad things ? What if one developpers types some kinf of "rm -Rf" in the wrong directory ?
you thought about different databases tables (I'd rather go with different databases ; with different users, to avoid anyone doing any bad request on the wrong database !), but that's not the only thing : what about temporary files ? cache, for instance ?
I'd really prefer having to fully separated instances ; even if it means have the sources / the framework twice on the machine -- and I'd really really recommend having two different machines !
About having the framework on SVN :
The more things you have on SVN, the easiest it is to get a new development environment set up : ideally, just one "svn checkout", and there's a new environment ready for the new developper who just joined your team ; coupled with a Virtal Machine you can give him (copied from another's machine), you can have developpers ready to work on your project in a couple of dozen minutes -- which is nice ;-)
Still, having the Framework in SVN is a PITA to update it : you have to delete it, replace it, re-commit it, ...
Using svn:externals (if you can -- depends on your setup / your framework), pointing to the framework's SVN server itself, might be a good thing to always be up to date (don't necessarily point to HEAD ; using a tag or a branch might be good enough for you).
Hope these few notes help...
Have fun !
1) I agree with Pascal MARTIN - its best for everyone to have their own local dev environment; that way they can play without stepping on each others toes. It may mean, then, that you want to have some type of test or staging environment where team members (and project stakeholders) can see the integrated, in-progress code.
2, 3) More generally, it sounds like you're asking how to automate/deploy to one or more environments. There are several commercial and open source options for doing this. We've recently started to use Capistrano (http://www.capify.org) and have been really happy with the results. It's a ruby tool, and written using ruby-on-rails-isms. If you're not familiar with those (I wasn't) it takes a little bit of reading and Googling to figure it out. However, at its heart is simply a means to define and run scripts on remote servers. Those scripts can be used on any type of deployment (we use PHP, for example). Two great things about Capistrano that address your question:
It knows about version control; whether you use SVN, git, or others, it knows (several ways) of pulling down the latest code from the repository and doing whatever is needed to update remote server(s).
It does transactions, so if something goes wrong with the build/deploy process, it can automatically rollback to a previous version
4) That's probably the simplist model; simply download a codeigniter installation and write your code in the applications/ directory. This could be hassle someday if you want to upgrade CI to take advantage of some new hot feature. You should be able to get around this by defining an svn:external link to the codeigniter, so that when they update, it gets rolled into your code as well. See: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html for more info...
I would like to setup two environments for my new website written in PHP. One - to develop new versions and test them. And second production where my actual stable version of website will be available.
Website in PHP will consist of many PHP and other files (JS, images, and so on). So I think how to prepare this environment in best way to make it easy to do source control, fast copy website from development environment to production environment and to make development version available for people on the web so they will be able to see actual work progress and suggest changes or report bugs.
Could you please give me some advice where to go from this starting point? Are there books about this (from practical point of view?) or do you have experience or tips what to watch out and what is important to make this process easy and good for me and other people involved in developing new project?
For starters use the following three:
SVN - this will give you source control and allow you to track changes. You may want to get GUIs on top of this (Tortoise is a popular one) to ease the learning curve.
RSYNC - this will allow you to streamline your syncing between local and remote site with a single command. RSYNC uses a diff engine to sync which means that incremental syncs happen in a matter of seconds. During intense programming, I will sometimes sync 4-5 times in one hour pushing out little changes real fast just because I can so easily.
MySQLDump - This will allow you to import/export data from your production site. I usually do this once a week to get production data on my local servers which not only gives me a local backup but also lets me toy around with production data on a local test environment.
Those three alone will save you a lot of time in the long run and allow you to scale. Later on you can look into an automated build tools, unit testing frameworks, xml documentation framework and the like to build some serious products.
I work with a setup like this, so I can give you some tips on how to do this. I've been doing this for a while now, working out the kinks here and there, and feel like this is a setup I can honestly say is pretty darn productive.
Small note: I work on OSX, so the specific applications used might be a bit different from you if you're a linux/windows user.
I run a production 'server' on my Mac, using MAMP (www.mamp.info) to easily supply me with an Apache server with PHP and MySQL. You could use a similar tool such as XAMPP or install everything manually, it's really up to you.
Then I have my live servers, where my websites and customer websites are hosted. For each new website project (let's take abc.com as an example) I create a subdomain called staging.abc.com, on which I do my testing. It's always a good thing to test things on the exact same hard- and software before actually going live.
I use Subversion (or in short, SVN) for my versioning needs, with the added bonus that I can easily add 'hooks' to automatically update my online production server whenever I send my newly updated version to the SVN server. SVN also allows you to easily work with more than one person on the same project. For more information on SVN and how to use it, I suggest the great (and free) online book found here: http://svnbook.red-bean.com/
So in short: I work locally with MAMP providing me with a local 'working' server. After that, I test online on a staging.abc.com location to see if everything works well, and to possibly allow others to see the project (in case you want your client to see what's going on, for example), and after that I actually publish the project by putting it on the actual domain.
There are many more things that can be done to optimize your workflow, but this should get you started.
Hope this helps!
-Dave
I prefer to have development occur on the developers local box if possible. If other developers are involved, you probably want to setup your version control such that both the database schema, javascript, css, and the php code can be checked out and setup on a developer's personal box pretty easily (assuming they have the correct LAMP/WAMP setup)
I've also seen it where people maintain a test website on a server where active development occurs. I would avoid this for active development, but use this for black-box testing of the latest checked in code (the latest build).
Once your test website checks out, then its a matter of exporting the code from your version control to the location the live website is. With svn, you can really just do an update of the live code with svn update specifying a revision or tag that indicates the current live version.
I would further recommend keeping some settings, like db access/username/pass, in a separate included file that is not version controlled. Keep this elsewhere, let developers plug in the access rights to their local database on their PC. On your server, plug in everything you need to access the database there. This should be really trivial code (defining a few variables) so not having it version controlled shouldn't be a big deal. If you like, you could version control a templated version, but I wouldn't put the real database info into version control.
Here is a pretty good starting place if you want to use MAMP or WAMP to develop locally and then push that to github and then update your live site from github:
http://www.mybringback.com/bringers/14509/git-local-and-shared-server-development-environment-with-ssh-setup/
Hope that helps.