I like to keep a pretty efficient development environment. I have several projects I manage at work, and I have these projects all to myself for the most part. Regardless of whether you are working in a huge IT consulting firm or in a basement by yourself, it's a great idea to automate as many mundane processes as possible.
One of the tasks that annoys me most is moving my code to our production web servers. It's a royal pain the ass to fire up SmartFTP/FileZilla/whatever, navigate your folders, connect, and so on, especially if you are frequently publishing. On top of this, manual FTP uploading can also be error prone. I'd like a nickel for every time I've overwritten production-specific config files with development copies.
The easiest way I could think to publish changes is to simply push a freaking button. So, a month or two back I found a simply FTP upload script. The script (I can't remember where I got it) often worked, but once my projects started growing in size, it would often time out and only a portion of my code would make it up. I figured the best solution would be to write my upload script that cycled through my project files and used a remote script to upload them one by one rather than in one big session. Sure, it's slower, but hey, it works and all I ever have to do is click one freaking button.
Below are the spoils of my endeavor and some commenting:
Grab the code here.
ftp_tools.php: Utility functions. Nothing to change here. echo_jsarray() recursively browses a directory and prints a Javascript object containing information about the files in it.
ftp_upload.php: The script that actually handles uploading a file passed to it. Here you want to change the $ACCOUNTS variable to hold the FTP login info for your various projects. Also change the $FTPADDR string to hold your server's address.
SampleProject.migrate.php: The script that handles uploading your files, one by one. There are some variables up at the top you'll want to change such as file exceptions and the directory you want to upload from. In UploadFile() you'll also want to define the account you want to use.
Setup: On our production FTP server, I have an account for each project. The root directory of each of these accounts is the project's root folder. Thus, I simply upload to the root folder for every project. Dump all of these files into a folder on your test server or something, grab jQuery 1.2.6 (minified) and add it to the mix, and you should be good to go.
It's a pretty rough, environment-specific way to do this, but it should be no problem to adapt to your own development environment. Bonus points: Figure out which files have been changed and which have not, and upload only the changed files. Add some error handling for when files fail to upload mid-stream.
One of the tasks that annoys me most is moving my code to our production web servers. It's a royal pain the ass to fire up SmartFTP/FileZilla/whatever, navigate your folders, connect, and so on, especially if you are frequently publishing. On top of this, manual FTP uploading can also be error prone. I'd like a nickel for every time I've overwritten production-specific config files with development copies.
The easiest way I could think to publish changes is to simply push a freaking button. So, a month or two back I found a simply FTP upload script. The script (I can't remember where I got it) often worked, but once my projects started growing in size, it would often time out and only a portion of my code would make it up. I figured the best solution would be to write my upload script that cycled through my project files and used a remote script to upload them one by one rather than in one big session. Sure, it's slower, but hey, it works and all I ever have to do is click one freaking button.
Below are the spoils of my endeavor and some commenting:
Grab the code here.
ftp_tools.php: Utility functions. Nothing to change here. echo_jsarray() recursively browses a directory and prints a Javascript object containing information about the files in it.
ftp_upload.php: The script that actually handles uploading a file passed to it. Here you want to change the $ACCOUNTS variable to hold the FTP login info for your various projects. Also change the $FTPADDR string to hold your server's address.
SampleProject.migrate.php: The script that handles uploading your files, one by one. There are some variables up at the top you'll want to change such as file exceptions and the directory you want to upload from. In UploadFile() you'll also want to define the account you want to use.
Setup: On our production FTP server, I have an account for each project. The root directory of each of these accounts is the project's root folder. Thus, I simply upload to the root folder for every project. Dump all of these files into a folder on your test server or something, grab jQuery 1.2.6 (minified) and add it to the mix, and you should be good to go.
It's a pretty rough, environment-specific way to do this, but it should be no problem to adapt to your own development environment. Bonus points: Figure out which files have been changed and which have not, and upload only the changed files. Add some error handling for when files fail to upload mid-stream.
Anymore development on this script?? It sounds great!
Would love to have an automated way to 'sync', even one way, the projects to our server without opening rsync, etc. etc.
Sounds pretty badass. I had a coworker that built something like this, although it was for pushing SVN to dev and production servers.
Thanks for the code!
Thanks for the script. I was looking for some AJAX that uses FTP in order to upload large files audio files which timeout in most browsers.
However, for you problem I highly recommend a version control system, e.g SVN, git, CVS, etc. You will never overwrite a file ever again, because you can always roll back your changes to a previous version.
I use SVN. On the Dev server my developers connect to SVN via https using .htaccess for user/pass. After someone commits their work file(s) to the repository a script runs to update the Dev site automatically with the new changes.
When we are bug free (for the moment), I roll the changes into production. After setting up the svn user on the production server, I simply run "svn up" from the shell connect via SSH. And viola the changes are in production. SVN does leave its trace in .svn files. But I redirect this http requests, when someone tries to view those folders.
@derby
We actually do use Subverison for our version control, but we don't use it for pulling production updates. That's quite an interesting idea, actually. The only problem is that our applications are compiled. (ASP.NET MVC) We have a continuous integration server to do production builds and tests, but moving the resulting binaries is the tricky part, as we do not want binaries in source control. For this, we use this set of scripts as a 1-button production push.
I'm really starting to get irritated at these scripts though (they can be a little quirky) and need to either rewrite them or find some Windows-y way of doing ftp syncs. There is a good perl sync program out there, but I believe it relies on SSH or SCP to work.