Related
I've stumbled upon the following problem and can't figure out a decent solution. I make websites in PHP for various clients. Like all clients, some will find bugs that need fixing, some will request updates to live sites after a few months and some do both.
When working on updates for clients, I like to preview them to the clients before putting them live.
I've used a couple of different solutions in the past, but none I'm happy with. What I've done so far:
Define VERSIONs and CURRENT_VERSION in the index. Visitors see the approved version. I send the client a specific link that sets a $_SESSION variable, which lets them see the new version. In the code I work with if's and switches to show new things depending on CURRENT_VERSION. This works, keeps all the code in one place and easily allows bugfixing, but riddles the code with stupid if(CURRENT_VERSION >= V2) statements. I also can't use this in CSS files.
Put all files in a "build1" folder, when starting on big updates that need previewing, I copy everything to a "build2" folder. I upload the "build2" folder for the client and password protect it. This works pretty well, however, if I have to bugfix build1 while working on build2, I have to make sure I copy fixes from build1 to build2.
Use a development server (some clients can provide this) this works the best so far, as the dev server is separate from the live site. It works much the same as the second solution, where I have to make a copy of the project, but it feels cleaner to me.
I am however looking for a better way to manage my code, possibly with the use of Git/SVN, but do not know enough about these things if they could help me.
A fairly typical paradigm these days is Development/Staging/Production. You don't need an entire development server for this approach either, VirtualHosts/nginx equivalent will suffice.
I'd suggest that the first thing you need to do is get your projects into Git, the quicker the better!
Disclaimer: This is my workflow, there are many like it, but this one is mine.
Here's an example of my current work flow.
GitHub
A separate repository for every project I've taken on
Development Server
Bare Git Repositories, replicating my GitHub (I'll explain this shortly)
/opt/git-bare
VirtualHosts of all my projects
/var/www/vhosts
Local Machine
I clone my bare repositories, as I need, for quick editing and commits. I'm not worrying about FTP'ing files back and forth or mounting anything locally on to my machine. I find this the BEST way to work on a project. When I am ready to check out some code on my development server, I simply commit and push my work to the bare repository, where I have a post hook that then tells my development VirtualHost to update itself.
This means that within seconds of commiting/pushing my work, from my local machine, I can see it on my development server through my browser.
When I am happy with what I have seen on my development server, I then push my bare repository up to GitHub. Git is a wonderful tool and all my local commits are also available within the logs on GitHub.
Staging
This is a clone, from GitHub, of my master branch on GitHub. This is what I use for showing to clients and getting changes signed off.
Production
My production server is a clone of a tag from GitHub. No matter what I do within my master branch, production will never be effected and should anything ever go wrong with one of my servers I have this tag easily available for rebuilds.
If you have any questions about this, please just fire away.
Before my long answer: if you're looking for a host that would kind of do this for you, stackable supports the concept of multiple 'enviroments'. I'm sure other hosting platforms offer similar features that allow essentially the same thing (AWS Elastic Beanstalk for example), but I don't know of one that is as core to the offering. Note: I don't have any connection to stackable, I'm not even a customer.
Define VERSIONs and CURRENT_VERSION in the index...but riddles the code with stupid if(CURRENT_VERSION >= V2) statements. I also can't use this in CSS files.
If I recall correctly, this is actually similar to how Facebook rolls out changes. You're right, it adds that additional logic; however there's an advantage as you're able to 'preview' the changes to more than a single user (say, all users that are admins, or all users in a specific geographic location).
And of course, the preview uses the same data - which means the user previewing the site will use it like they normally do (instead of odd interaction with contrived data).
While you're right as to the disadvantage, there are cases where this is a useful way to test new features.
Put all files in a "build1" folder, when starting on big updates that need previewing...however, if I have to bugfix build1 while working on build2, I have to make sure I copy fixes from build1 to build2.
Here you're essentially deploying two versions of the project to the same server. In the example you give, you're putting the second copy under the original webroot - but depending on hosting, you could just assign a subdomain and work from two different web roots.
The advantage is similar to the first, as both installs could easily share the same data, and if all requests pass through some kind of front controller you can add logic to only show changes to select users (or use some kind of Basic Auth as you describe).
In this case putting your project into version control (as I see it, git would be better than SVG for this) can make this much easier. On your development system simply switch between branches to work between the existing version and the new version.
If you fix a bug in the old version, you should be able to easily (or more easily than your current workflow) merge that fix into the new version with a few commands. If you fix a bug in the new version which was also in the old version, doing a cherry-pick can allow you to just merge that single change back into the old version.
Deploying your code can be as basic as logging into your web server and doing a git pull, or you could use tools to automate the deployment. Essentially your deploy of the old version would be based on the 'master' branch of your repository (or something similar to that), and the new version would be based off whatever you've called that branch.
Use a development server (some clients can provide this) this works the best so far, as the dev server is separate from the live site. It works much the same as the second solution, where I have to make a copy of the project, but it feels cleaner to me.
As this is very similar to your second method, adding version control will certainly make this easier as well.
There are plenty of resources explaining how to deploy from various version control systems to various hosting platforms, but hopefully this illustrates how that will fit into what you're already doing and make things easier for you.
In the past, I have been developing in a very amateurish fashion, meaning I had a local machine where I developed and tested code and a production machine to which I copied the code when I was done. Recently I modified this slightly to where I developed locally, checked the code into SVN and then updated the production machine through SVN.
Now I would like to start a new project and improve my workflow. Ideally I had the following in mind:
Have one or more local dev environments
Develop and test on local machine(s)
Use SVN (or Git) as code repository
Use a build tool to set up new environments (either dev, staging or production) and deploy code
Since I am not very familiar with this process, I am looking for suggestions on how to best set this idea up and the tools to use, especially when it comes to the build tools. I was looking into Ant and Phing (possibly make), but I am so new to this that I would really like to get some guidance. Are there any good tutorials or books about PHP deployment, especially for beginners? What I am especially interested in are the following topics:
Deployment to different types of servers with different settings (e.g. dev uses different db, db passwords, PHP error reporting than production or staging).
Deployment that automatically pulls code from SVN.
Deployment that temporarily sets a "Maintenance" page for production environment.
Once I mastered the above, maybe even do some testing in the build process.
I know my question might sound quite confused... I admit, I am new to this and might be a little off the target in what I really need. That's why any help is greatly appreciated.
I would suggest making your testing deployment strategy a production-ready install-script -- since you're going to need one of those anyway eventually.
A few tips that may seem obvious to some, but are worth pointing out:
Your config file saved in your VCS should be a template, and should be named differently from the file that will eventually contain the actual settings. E.g. config-dist.php or config-sample.conf or sample/config-mysql.php or something along those lines. Otherwise you will end up accidentally checking in a server-specific configuration file over your template.
For PHP deployment, anticipate that some users will not be able to run server-side scripts through any mechanism other than the web server itself. A PHP-based installer is almost non-negotiable.
You should include a consumer-friendly update mechanism, and for that, wordpress is a great example of a project to emulate. A PHP script can (a) download the latest build, (b) use the ftp functions to update your application's files, and (c) execute an update script which makes the appropriate changes to the database, etc.
For heaven's sake don't do like [redacted] and make your users download and install separate patches for each point release. Have them download the latest (final) release which contains all the updates to date, and applies the correct ALTER TABLE functions in sequence.
Whether the files are deployed via SVN or through FTP, the install/update mechanism should be the same: get the latest files, run the update script. The updater uses the version listed in the PHP script and the version listed in the DB, and uses that knowledge to apply the appropriate DB patches in order. As for how to generate those patches, there are other questions here that you can refer to for more info.
As for the "Maintenance" page, just use the version trick mentioned above to trigger it (compare the version in the DB against the version in the PHP code). It's also useful to be able to mark a site as "down" to the public but make it visible to admins (like Joomla does), which you can trigger through database or filesystem flags.
As for automatically pulling code from SVN, I'd say you're better off with either a cron script or with commit triggers than working that into your application, since it wouldn't be relevant to end users.
This isn't exactly part of your question, but it's relevant:
If you go into distributing code intended for a wide audience, I would advise you to go with building and distributing OpenSSL-signed PHAR packages. You can distribute them over HTTP without a problem, and because they're OpenSSL-signed, you're also mitigating the risk of man-in-the-middle attacks and protecting end-users/customers/clients from someone injecting code if you want to setup an automatic or one-click update.
There's a set of tools I've contributed to in the past that work great for this, but you'll either need PHP 5.3, or you'll need PHP 5.2 with PHAR installed via PECL. https://github.com/koto/phar-util
As far as testing goes, PHPUnit is the de facto standard.
If you are interested in using Git then you should check out this build system from CodeMeme. From what you described it sounds like it would be a good fit. You can add it to any project as a submodule and with the included code you can tailor a build script that will deploy to different multiple servers in multiple environments. It uses Git to build the code for deployment but unfortunately SVN is not supported.
https://github.com/CodeMeme/Phingistrano
I have heard that uploading your website with FTP is now for n00bs, but it's the only way I've known how for the 8 or so years I've been building websites. Apparently all the buzz now is using a version control system, like SVN or Git, and somehow using SSH to upload only the files that have changed (if I understand correctly). I'm wondering if someone could explain or point me to a "comprehensive" guide. What do I need to install, and will my shared host (Dreamhost) be compatible? I currently develop on a WAMP environment. I have never used version control and wouldn't know where to start. I usually develop with a framework such as CakePHP or Zend.
You've got things mixed up a bit. A version control system is used internally to keep track of your code during development. With centralized systems like SVN, you regularly upload your code to a SVN server, which keeps track of what has changed, makes sure conflicting changes are merged correctly, and keeps a history so you can roll back changes.
Decentralized or distributed version control systems eliminate the one central server, instead allowing every single copy of the code to track its own change history, and then letting you merge and combine these separate branches at will.
But once you have a complete product, you push it out to the production server any way you like. FTP is certainly one option for doing that.
For the file uploads, what you are looking for is rsync. There is a Windows wrapper for this called DeltaCopy and the DreamHost wiki has instructions.
First you'll want to decide what you want to use for version control. I hear great things about Git, but am still an SVN user myself.
Dreamhost actually lets you create SVN repositories with their webpanel, very keen there and I can't remember but I thought they had some additional really nice features to help.
I would suggest reading or skimming through at best: http://www.svnbook.org it is very comprehensive if you plan to actually use SVN over Git.
Everyone is completely missing the point. Development using a version control system is a great thing and has massive upside even for developers working on their own. The question here is about deployment using version control systems.
This is a newer and great idea, consider something like Magento which has 6,744 files in the base install, not mentioning when you start adding your own skins which usally run to around 500 files. Using version control to DEPLOY something like this saves major time uploading this many tiny files via FTP as only the modified ones are sent.
Asside from this, I've never actually tried deploying like this so I can't offer any real world experience, however there are several good articles on how to get this setup, a good one can be seen here.
Here's an wiki that should give you all the information you need on adding Subversion to Dreamhost.
http://wiki.dreamhost.com/index.php/Subversion
I've used Subversion now for my sites, and it does make it much easier. I use Aptana on my Windows machine and upload everything through that program. It allows me to compare old versions, revert to them, branch off new versions, etc...
It's a huge timesaver!
Eric Sink's articles about source control are a great place to learn about the basic concepts.
http://www.ericsink.com/scm/source_control.html
I also develop with Zend Framework and here is how I use FTP and Version control.
On my local machine I have Subversion and TortoiseSVN installed.
If I start a new project, I set up an SVN repository the way I like it (I use the trunk/branches/tags system).
I checkout an initial working copy from the trunk to a project folder in my local webroot.
I create a new project in Aptana and set the project path to my project folder on the localhost.
Aptana understands that this project is versioned and shows appropriate icons on each file. I can do many of the version control functions directly in my file tree in Aptana, no need for any shell or even Tortoise.
Once I have a stable, deployable version of my app, I create a version control tag. Then I do an export of that (unversioning it).
The exported app is then uploaded via FTP.
That's how I do it at the moment anyways, maybe it clarifies somethings. Tips on improving the procedure are welcome!
As others have said, you can set up version control locally ... or on your host. I recommend you do whatever works best for you.
You mention using Dreamhost. I support one small site there, and know that they do allow uploading via scp and sftp. This would allow you to upload your files with your password encrypted. (And you don't have to adopt a version control method if you don't want to! ;-) Scroll down the sftp page I linked to and you'll find some suggestions for scp & sftp clients.
FWIW, if you're using Windows, I've used WinSCP for years and liked it. Also, if you want full login access, I suggest PuTTY; its full download also includes command line based clients for sftp and scp.
There is no problem using ftp to upload. The only disadvantage is that the password is transferred as plain text.
It would be good to have a local version control system, that would allow you to easily see changes between versions, and quickly revert to an older version, and much more...
I don't think there is a need to install a version control system on your shared host. Only if you want to access the version control system from different sites (at home, at work, while traveling), it can be handy.
There is an awesome plugin for bzr called bzr-upload, designed exactly for your kind of use-case. bzr is very light-weight (no need to set up any repository) and super easy to start using, even if you haven't used any kind of source control before. It's a plugin for bzr and every time you make a commit on your local machine, it will s/ftp the changed files up to your web host. It doesn't push up all the version control info, just the files themselves.
I am developing a website using CodeIgniter and PHP. Some of my friends suggest I start using Subversion to take care of my organization. Could someone give me a basic explanation of what SVN is without the jargon and also if it is practical for a framework where 5 files are needed to run a single page?
Subversion allows you to store your source in a central location, make changes from multiple places (ie. laptop, desktop), track changes and revert changes to your source tree if needed.
Have you ever made a big 'improvement' and then decided you were going in the wrong direction? With Subversion you can revert to the version of your source before you started heading off in the wrong direction.
Or how about this, you make some subtle changes to the codebase, but don't notice that you introduced a new bug until much later. You can use subversion to revert to previous code versions, helping you track down the change that introduced the bug.
It is more valuable when sharing the source with multiple developers, but even for my single developer projects I find it very handy to have all my source and changes in a Subversion repository.
If you combine it with Trac, you can then keep track of bugs/features, milestones, and use the Trac Wiki to document your project.
Every single project (even with only one developer) should be under source control, no matter what framework or language you are using.
Using simple words, Subversion will keep a history of your code files, should you like to revert them to a previous state or restore a copy in case of a disk crash (SVN must be on another computer in this case). It will also help you see easily the differences between two versions of a file.
For more information, just read TortoiseSVN user's guide, it has a pretty good overview of Subversion.
Here's some good info : Chapter 2. Basic Concepts
SVN is a version control system. It is used as a central repository for all of your code.
A significant strength of SVN is that it uses a Copy-Modify-Merge work flow model versus a Lock-Modify-Unlock model. The idea behind this is that each developer checks out or copies (copy) their own version of the code, works on it (modify), checks it back in and reconciles any changes (merge) that may conflict with other work another developer has done.
This is really handy as if you wanted to work on a piece of your code, you won't have to worry about the file being locked because someone else is working on it.
If anything, developers should use SVN to catalogue all revisions of their code and revert back if needed.
SVN is a version control system - which means that it stores various previous versions of a given file, and allows many people to work on the same file, and in the end put all the changes together. It also helps you go back to a previous version if necessary.
You should use that in your project if there are a lot of people working on the project. But even if you are the only one working, it will be easier to manage the project if it is on version control.
It's a way to keep control of versions. You could think of it as some kind of incremental backup. You send your code to the SVN server and it saves only the differences from the last version. This way, you can go back to an earlier version if you need it. It also allows you to work with more people and merge differences with ease. I say, you should use it. It's easy and useful.
Irrespective of what software you produce and even if you are on your own, SVN has to be used. I depend on it every day. Its the one software tool I could not live without. If you can install it off-site it gives you backup as well.
Simple things like being able to do a diff on the previous version of a file when you are making changes, can be a great help.
Use Toortoise under windows for the client side. It integrates into Windows and is just great to use.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have absolutely no idea about version control. Only that it can be very useful in many ways.
I have found a few related questions but none that start from the absolute beginning.
I am the only developer at my work using Mac OS X and traditionally just been using FTP.
Can anyone help me with version control in relation to PHP projects (does it matter)?
Yes, try it out, it's worth it. And the language you are using doesn't matter. It's working great with PHP for me and it will for you too.
Benefits
If you are the only developer, it is indeed easier to go without version control. However, you will find great benefits to using a version control system. Some of the easiest benefits will be:
Never wondering what is your latest version once you go back to a project (no more myproject090201-archive2-final6.zip)
Never fear to start off some major refactoring, if you make a mistake on your file, you'll just rollback to the latest version
If something stops working in your project and you have the feeling it worked at one point, you can test some of the prior versions easily and look at the difference between the working version and the non-working version to find what broke the code
Additional backup of your current project, and even better if it's not on your machine... of course, additional points for backing up your version control system, we're never too cautious, you don't want to have to restart that month-long project do you?
Choices
As some have said, you have a few choices for your version control system and I guess you'll want a free one to begin. There are a few excellent commercial products but the free ones have nothing to be ashamed of. So here are some very popular free version control systems:
Subversion (also called SVN)
Git
Mercurial
Bazaar
Centralized versus distributed
Subversion has been there for a while and it's one classified as 'centralized'. Meaning everyone will always go fetch the latest version and commit their latest work to one central system, often on another system although it can easily be on your own machine. It's a process easy to understand.
The three others are called 'distributed'. There's a lot of different possible processes as it's a more flexible system and that's why those three newcomers are getting a lot of traction these days in open source projects where a lot of people are interacting with one another. Basically you are working with your own revisions on your own machine, making as many copies as you need and deciding which versions you share with other people on other computers.
The trend definitely seems go towards distributed system but as those systems are more recent, they are still missing the GUI tools that makes it really user friendly to use and you might sometimes find the documentation to be a bit lighter. On the other hand, this all seems to be getting corrected quickly.
In your case, as you are working alone, it probably won't make a big difference, and although you'll hear very good points for centralized and distributed systems, you'll be able to work with one or the other without any problems.
Tools
If you absolutely need a GUI tool for your Mac, I'd then choose SVN to get initiated to source control. There are two very good products for that (commercial):
Versions
Cornerstone
And a few other ones (such as the free svnX) that are becoming a little bit old and unfriendly in my opinion but that might be interesting trying anyway.
If you don't mind not using the GUI tools, with the help of Terminal you'll be able to do all the same things with a few simple command lines with any of the aforementioned systems.
Starting points
In any cases, you'll want some starting points.
For Subversion, your first stop must be their free book, Version Control with Subversion. Take a few hours of your day to go through the chapters, it'll be time well invested. The introduction chapters are a good read even you don't want to use Subversion specifically because it'll get you to understand version control a little bit better.
For a distributed system, I've had fun with Mercurial but it's an easily flammable subject so I'll let you make your own choice there. But if you end up looking at Mercurial, have a look at this blog post, it was an excellent starter for me that'll get you up and running with the basics in a few minutes if you're already a bit accustomed to version control in general. Anyway, drop by Mercurial's homepage and have a look at the Getting Started section of the page.
Conclusion
Give it a go, invest a day trying it out with a few bogus files. Try out renaming files and directory, erasing, moving things around, committing binary files versus text files, resolving conflicts and reverting to older versions to get a hang of it. These are often the first few hurdles you'll encounter when playing with version control and it'll be painless if it's on a non-production project.
In any cases, it's something well-worth learning that'll be helpful with your solo projects as well as if you end up working with other developers at your current job or your next one.
Good luck!
The type of code is irrelevant.
One open-source and popular version control system is Subversion and there is a very good overview/manual here.
I use Git for PHP development.
It's fast, flexible, reliable, clean (CVS and SVN create a lot of hidden folders that I personally don't like).
Its distributed nature allow to work the way you want (with or without a central repository).
You can find more about it here:
Gitmagic
Speed Benchmarks
Moreover, you can get the Eclipse PDT (PHP Plugin) and use Subclibse in the IDE.
Versions is working well for another developer I work with. Additionally, if you are using Textmate the SVN bundle provides pretty much all you need for most parts of the Subversion workflow. I really like it.
The Project Plus plugin takes it a step further by adding small unobtrusive badges to versioned files in the project tree, showing at a glance the state of files in a project.
If you're on a Mac, do yourself a favor and pick up Versions, a beautifully designed (and highly functional) Subversion GUI. You'd do best to learn the terminology and get an idea of how Subversion works using a GUI before you jump to the command line. Once you're able to commit revisions of your code and run updates to get other people's work, then go back and read the red bean book (it really is the best way to learn Subversion in-and-out).
http://versionsapp.com/
use bazaar http://bazaar-vcs.org/
it's very nice and you can start using it in minutes.
Check out other options too - Miscrosoft's TFS (this not only used for source control system but for defect tracking, project management etc etc) , Bazaar, Git are popular ones.
Alex,
Version control (and some will scathe me for this statement) is not a trivial matter, and even very experienced developers get themselves into trouble. The most frequent causes for frustration are limitations of a particular product (Visual Source Safe is a famous one), and members of a team not following the same process, or not understanding the process at all.
This should not stop you from looking into using a source control tool - the opposite is the case. You can only use a tool effectively if you understand what it does and why.
I would recommend that you look into CVS. It has been around for many years, it is relatively simple to install, set up, and use, and while there are GUI clients available for most platforms, learning it from the command line may provide the best access to its features.