I've been designing and programing websites for the most part of my adult life. I've always done this solo, freelancing mostly and working from a single machine.

Currently, I use Dreamweaver for the coding and also the publishing of the sites (via FTP) and I work directly on the live sites. That's about the extent of my "workflow". I use mainly PHP and the framework CakePHP.

I think it's time to adopt better developing practices and this is what I have in mind and what I need help with:

  • Setting a remote testing/developing server so I can work and test on dev.address.com and then deploy to address.com. I need a good solution for deploying the site once I'm done working on the dev server. Right now I would have to scan/compare the whole site and upload only the updated files, which would suck if I have to make multiple deployments in a single day.
  • I need to be able to work from 2 different computers: my laptop and my desktop. Again, right now I would have to scan/compare the whole dev site and update my files everytime I switch from one computer to the other. If I forget to do this everytime I switch, I might lose hours of work.
  • Although I work be myself, I would like to get used to working with something like GIT for version control. Perhaphs this could even make working from 2 different computers easier or more streamlined. Also, it would be nice to be able to rollback the site to a previous version if the need arises.

I would greatly appreciate any advice or guidance about how to solve these issues. I've reading about different kinds of workflows they nothing really seems to makes sense in my particular case.

Thanks in advance.

  • If you have no experience with git etc I would recommend you to create a GitHub account, download their client software so you can visually see how it works. Then in the client you do: help.github.com/desktop/guides/contributing/… Then install the client on your laptop. There you go to the GitHub website and there is a button which allows you to clone the project to your laptop. Now you have a sync between them. There is a sync button at the right top to get updates. If you have that setup we can help you with deployment. Sep 10, 2016 at 11:55
  • I'm happy to write an answer about using git to significantly improve your life, but before I do I'd like to know more about your deployment targets. You mention that you're publishing via FTP, which suggests you might be deploying stuff to shared hosting. Is that the case? If so, are you married to that? How comfortable are you managing a *nix machine from the command line?
    – timdev
    Sep 10, 2016 at 20:11
  • "Right now I would have to scan/compare the whole site and upload only the updated files" - wouldn't a logical first step be to automate this, so you can do this comparison/copy with a single action? Make sure your deploy process is able to easily "revert" to the previous version. It will save your customer downtime whenever something doesn't work for whatever reason.
    – Brandin
    Sep 11, 2016 at 12:40
  • @LucFranken Pretty much no experience at all but I'm familiar with how the process works. I'm aware one approach would be to, as you suggest, create a repository and then work on it from both computers. Since I need to work on a remote server for testing I would have to use Dreamweaver, for example, to code and then publish via FTP to the test server, and once I'm happy with the results, commit the changes to GitHub. Is that correct? Is there a better way?
    – Francisco
    Sep 11, 2016 at 23:23
  • 1
    @Francisco: Ok, so you first do the GitHub things as explained. Then for deployment to get started: Put a simple file deploy.php on your server. Content: shell_exec("git pull [email protected]:yourusername/yourrepo.git 2>&1"); and then create a web hook on the push event (developer.github.com/webhooks with: developer.github.com/guides/managing-deploy-keys/#deploy-keys read-only) where you enter the public url of that deploy.php file. Now it will auto-deploy every time you make a push to the repository. This is the most basic situation to get used to it. So you commit-> click sync Sep 12, 2016 at 9:20

3 Answers 3


There are several tools that you can use to improve your workflow. You don't need to adopt them all at once, but they work very well in concert, so you should plan to eventually adopt most of them.

This got quite long, but I've tried to point you in various directions that will be valuable in the near-term.

The TL;DR: "Start using git, and get comfortable running a basic linux server. Once you've gotten those two down, you'll have solved your immediate problems and have a plenty of potential next steps to examine."

VCS (git)

You want to adopt some version control system. git is the default choice, since it's ubiquitous. Adopting a VCS like git is sort of a prerequisite for things like automated deployments, automated testing, and ultimately full-blown continuous integration (CI). It even helps with manual deploys, and a little discipline about tagging releases can make rolling back a bad change a lot easier and more predictable.

You'll want to maintain a remote repository as a central source of truth. You'll have your remote repo set as the origin remote in your local repositories. When you sit down to work, you'll git pull to make sure you have the most up-to-date version of your code. After making some commits locally, you'll want to git push to your remote so your changes will be available elsewhere.

You'll want to host that remote repository somewhere reliable. You could just stick it on some VPS and access it via ssh, but you'd be leaving some nice tools on the table.

The quick-and-easy solution is to create an account at bitbucket.org. It's free, including private repositories, and includes a nice web interface with an issue tracker, etc.

If you're concerned about putting your code in a third-party service[1], or you want an opportunity to start managing a VPS (which is a great thing to do if you have the time and mental bandwidth), you can grab a $10/month VPS and install GitLab Community Edition. It's a GitHub-like, but you run it on your own server. It's pretty great, and the omnibus installer makes it relatively straightforward to install and update.

As mentioned in Sorin P's answer, GUI clients are available for git. SourceTree and GitHub Desktop are both good. I prefer the former. That said, you should git using the CLI tools as your primary interface. The CLI works everywhere.

Git can be a bit intimidating, but you can start small and grow. That said, a basic understanding of how git works will serve you very well. Git From the Bottom Up is pretty fantastic. Understanding the terms on the first page is essential.

To start, you'll want to have at least a sense of how git operates, and be familiar with the basic sub-commands clone, checkout, add, rm, status, diff, commit, pull, and push.


I can't recommend using a local virtual machine enough, especially if your local environment is Windows. Get familiar with VirtualBox and Vagrant ASAP. This allows you to develop against a local environment that closely resembles your deployment environments. It's also a great way to get your basic Linux-admin skills up-to-snuff.

You'll use VirtualBox's "shared folder" feature so that a directory on the client (virtual, linux) machine is mapped to a directory on the host (physical) machine. This means your virtual machine is running "headless", with no graphical interface, just a console. Your editor/IDE, git client, etc, all run on your everyday computer, but your web server, PHP interpreter, SQL database, etc, all run inside the virtual machine.

As far as Editor/IDE goes, you're really free to use whatever you like. I know people who code in Vim, I was an emacs holdout for a long, long time, others prefer fancier IDEs. That said, I highly doubt Dreamweaver is optimal.

My IDE of choice for PHP is PHPStorm. It ain't free, but it's not expensive, and if you develop in PHP for a living it's a no-brainer IMO. It understands git, has a nice database client built in, debugging with xdebug works very well, and the static analysis becomes something you can't live without.

If paying is out of the question, you can usually get their "EAP" builds for free. It's essentially the beta of their next release, but is typically very stable.

The other alternative is NetBeans, which is free, and good. But not as polished as PHPStorm last I checked.

If you prefer something lighter-weight, lots of people like Sublime Text, and new(er) comers like Atom, or somewhat surprisingly, Visual Studio Code.

Bottom line: spend some time checking out at least one or two alternative editors/IDEs. Most people I know who clung to Dreamweaver did so because of it's FTP integration. But you shouldn't be relying on that anyway (see below).


Deployment is about getting a new version of your site or app up onto a server. The method you choose will depend on what your hosting infrastructure looks like.


I host just about everything on commodity VPSes. There are a ton of providers. DigitalOcean and Linode are popular in this crowded field. Amazon's AWS provides VPSes as well (the "EC2" service), but I don't recommend novices start there. AWS really shines when you need automation and orchestration, but it's hard to estimate costs, and the complexity is intimidating.

The core of updating a reasonably modern framework-based PHP project to a VPS looks like this (if done completely manually):

localhost$ ssh [email protected]
myvps$ cd /path/to/project
myvps$ git pull 
myvps$ composer install

That's not what one would call a best practice, but if you get to the point that your deploy process looks like that, you're already miles ahead of trying to sync stuff over FTP.

From there, you can start looking into deployment tools. Capitstrano is the grandaddy, but others exist. Because these tools automate things, they can be a bit smarter than people. For instance, capistrano will check out the correct version of your sources locally, bundle them up, send them over to the server, expand them into a timestamped directory, and then manipulate a symlink to point your webroot to the new version. This makes rolling back (often) as simple as swapping back the symlink to the previous version. It's definitely worth it to read up on these tools; they may or may not be overkill for your needs.

Another tool to be familiar with is rsync. Rsync's job is to sync trees of files efficiently, and it's very good about it. If you don't want to run git on the server, you can build your own deploy process around local git and rysnc where you checkout (or git archive) a local tree of your sources, do whatever build process is necessary (say, composer install), and then rsync the whole thing to the server.

Any of these tools can be used to build up an automated deployment, using simple shell scripting. I suggest you aim to have a script that pushes (or pulls) a new release, and does so in such a way that it's very easy to roll back if things go wrong (the capistrano-style symlink trick is a great place to start).

Non-VPS Environments

I can't really speak to these. There is old-timey shared hosting like you're used to, where you're pretty much limited to SSH with no shell access. There are also Heroku-alike platform-as-a-service offerings for PHP, but I've never liked that idea.

That said, if you're absolutely married to shared hosting, you may be able to approximate an rsync-style workflow using a decent CLI FTP client.

What About Databases?

Deploying code is great, but sometimes a new code release requires some kind of database change (say a new column on some table, or some update that fixes artifacts of some bug you've just fixed).

This gets more complicated (especially when thinking about roll-backs), but there are tools to help. I've used both PHPmig and Doctrine Migrations with great success, and there are others.

The basic idea here is that you write small migration classes and the migration tools track which ones need to be run, and then run them. Your little bash script gets a new line it it somewhere that says something like phpmig migrate so when you run your deploy, any pending DB migrations get run automatically.

[1] Most people shouldn't be concerned IMO, but I don't know your circumstances, politics, or level of paranoia.

  • +1 for VPSes and git over VPS, that's pretty much the modern world vs the dark ages
    – ZJR
    Sep 12, 2016 at 1:53
  • Boy, this is a lot to chew on. It'll look like I either gave up or failed because I doubt I'll reply soon, but know I'll be researching about every aspect you mention in your answer, I can't tell you how much I appreciate it.
    – Francisco
    Sep 12, 2016 at 3:26
  • As an update, I got a DigitalOcean VPS with LAMP running, and my dev website running on it. Tried Virtualmin but ended up starting all over again and doing everything manually. I've got to a point where I can manage different virtual hosts and even installed PHPMyAdmin. Did exactly the same in my local machine via VMware. Same Ubuntu version as my VPS running "headless". Right now I need to setup GitLab on the VPS and figure the "shared folder" stuff you mentioned. I'm assuming that's where I do all my work and also the root of my website in the local virtual machine.
    – Francisco
    Sep 13, 2016 at 19:05
  • @Francisco Glad to hear you're on your way. Avoiding control panels like Virtualmin is good, they're just big piles of unknown code running on your server -- never a good thing. I suggest you skip GitLab for now and just grab a bitbucket account in the meantime.
    – timdev
    Sep 13, 2016 at 20:11
  • @timdev I was thinking I could grab a free GitLab account to maybe get used to it before making any changes in the VPS. That got me thinking about deployment, both to the dev and the live server. Would having GitLab on my VPS make deployment easier? If I get a free bitbucket or GitLab account, how should I go about deployment to the dev server?
    – Francisco
    Sep 14, 2016 at 13:30

My recommended combo would be:

  • Netbeans IDE on both computers
  • Use a Git repository on both computers for dev.address.com
  • When needed, use GitFTP to deploy only the differences to address.com from dev.address.com repository

With GIT FTP you can have multiple profiles to deploy changes to multiple servers.

Optionally, you can use SourceTree or GitHub Desktop for a nice graphical interface to your Git repo.

  • I'll checkout the Netbeans IDE. Can I publish to the remote testing server to see and changes AND commit changes to Git?
    – Francisco
    Sep 12, 2016 at 0:03

Keep the computers synced with BitTorrent Sync (now rebranded "Resilio", but the free version for individuals is what you want), it works on LANs, no central server, quite darn fast. Perfect for a single user that switches devices.

Or use Dropbox, that's as dumb as it gets: web projects at the coding phase, beyond the design phase, where the big PSTs have already been scaled down, take little space, so a free Dropbox might just do. Also, vital stuff kept backed up. Disasters happen.

Use git on each project, you'll eventually learn to use it to resume previous versions, (you will probably do some missing HEAD / multiple HEAD disaster along the way) but for now, just learn how git init . and git commit work. That's the thing you should start doing, not now, yesterday.

Git handles most of the pains of working in a team. Once the team knows how to use it.

Keep database dumps (.sql files) of working versions, add them to git repositories, add a script that uploads them to the right database, too.

  • What do you mean with "resume previous versions"? I'm trying to wrap my head (no pun intended) around the HEAD concept but are you referring to the very likely chance of resuming work on a different machine without syncing first?
    – Francisco
    Sep 12, 2016 at 3:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.