I work at a small LAMP Development Studio where the idea has been to just get the code done and go on to the next item on the list.
The team works in Zend Studio 5.5 connected to the Live server via FTP or SFTP. What they love about this is the speed of their deployment of code (since its just modifying live code).
But of course this is not good due to many obvious reasons.
I would like to move them to a Versioning System (CVS, SVN or any other tool) but the catch is, I am not their senior so I need a carrot for them to start using this.
What kind of setup would I need to build on their machine so they can code along as usual?
What I would do is create this setup on my machine and then show them.
I know this is kinda unusual but it’s turned into a passion of mine to change their way of thinking from the usual hacking of code to structure and elegance. Thanks.
UPDATE (for Jonathan Leffler’s answer):
- Yes
- No
- Yes, they really do
Question also, the studio makes a centralized CMS system that is hosted on hundreds of sites, they need to modify individual sites, should the sites be in the main compository or within their own one?
Questions:
Have you (they) never had a disaster where you (they) needed to revert to a previous version of the web site but couldn’t because they’d broken it?
Do they use a staging web server to test changes?
Surely they don’t modify the code in the production server without some testing somewhere?
I suspect the answer to the first is ‘yes (they have had disasters)’ and the second ‘no’, and I hesitate to guess the answer for the third (but. from the sounds of it, the answer might be ‘yes, they really do’). If that’s correct, I admire their bravado and am amazed that they never make a mistake. I’d never risk making changes direct on a live web site.
I would recommend using a version control system or VCS (any VCS) yourself. Work out the wrinkles for the code you look after, and develop the slick distribution that makes it easy (probably still using SFTP) to distribute the VCS code to the web site. But also show that preserving the previous versions has its merits – because you can recover who did what when. To start with, you might find that you need to download the current version of whatever page (file) you need to work on and put that latest version into the VCS before you start modifying the page, because someone else may have modified it since it was last updated in your master repository. You might also want to do a daily ‘scrape’ of the files to get the current versions – and track changes. You wouldn’t have the ‘who’, nor exactly ‘when’ (better than to the nearest day), nor the ‘why’, but you would have the (cumulative) ‘what’ of the changes.
In answer to comments in the question, Ólafur Waage clarified that they’ve had disasters because of the lack of a VCS.
That usually makes life much easier. They goofed; they couldn’t undo the goof – they probably had annoyed customers, and they should have been incredibly annoyed with themselves. A VCS makes it much easier to recover from such mistakes. Obviously, for any given customized site, you need the (central) backup of the ‘correct’ or ‘official’ version of that site available in the VCS. I’d probably go for a single repository for all customers, using a VCS that has good support for branching and merging. That may be harder to deal with at first (while people are getting used to using a VCS), but probably leads to better results in the long term. I’d seriously consider using on of the modern distributed VCS (for example, git), though lots of people use SVN too (even though it is not a distributed VCS).