A community in which webmasters can ask for help with topics such as PHP coding , MySQL , IT jobs, web design, IT security.
|Converting a development team from FTP to a Versioning System||#1|
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, 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?
posted date: 2008-12-28 15:09:00
|Re: Converting a development team from FTP to a Versioning System||#3|
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).
posted date: 2008-12-28 15:23:00
|Re: Converting a development team from FTP to a Versioning System||#4|
you can use tortoise svn client to create and work with a repository on your local machine on some other file path then your working path is....maybe try to setup and use that for yourself and show them after a while what it can do for you. another cool thing might be installing trac (http://trac.edgewall.org/) on your server if you have access and privileges to do so, or maybe in some virtual machine on your own development machine. you can map trac to your svn and get svn changes in web interface which you can show to the project manager. maybe he will fall for that he'll be able to see code changes easily through the web interface. of course, you can do that with only apache + svn module, but this is nicer as it offers a path to ticketing and roadmapping (milestones and stuff which managers might dig :o) )..good luck anyhow :) . at least, use it for your work on your local machine as there's only a gain for you doing that.
posted date: 2008-12-28 15:33:00
|Re: Converting a development team from FTP to a Versioning System||#5|
Love the comment about the connection to trac, thanks.
posted date: 2008-12-28 15:36:00
|Re: Converting a development team from FTP to a Versioning System||#6|
You can install SVN on your local system for the demo. There are some tools to integrate Zend and Eclipse to SVN. I think in addition to doing a demo of SVN, you should probably give them a presentation of some of the benefits it will bring (probably during the demo).Go to this link for some ideas: Do I Really Need Version Control?
posted date: 2008-12-28 15:37:00
|Re: Converting a development team from FTP to a Versioning System||#7|
i love the software, been watching it for a while and just got it set up 2 weeks ago, and i'm the happiest person since then... :) . simple, useful, easy to use... and as of 0.11.x easy to install. i got it up and running in clean debian installed in VM in less than half an hour.
posted date: 2008-12-28 15:41:00
|Re: Converting a development team from FTP to a Versioning System||#8|
Ólafur, you mentioned that "the studio makes a CMS system that is hosted on hundreds of sites." This itself may be the carrot that you need. If the team is often deploying updates to these hundreds of sites, then using branches inside a version control system may make this process much easier for everyone. That could be a huge time-saver and thus would provide an incentive for people to learn the version control system.It sounds like these sites are all related -- customized versions of the same CMS. In that case, you should put all of the sites in the same repository, in addition to the un-customized CMS product. Then you can configure them all as branches of the same central product. If you use separate repositories, there aren't easy ways to create branches to relate the customizations to the main product. (I think you can do it with Subversion, and most likely others, but it's complicated and unnecessary if all the developers work for the same organization.)
posted date: 2008-12-28 15:43:00
|Re: Converting a development team from FTP to a Versioning System||#9|
Sorry i should have stated that the CMS itself is centralized but you have a point since there are some elements within each site that i wish we could change.
posted date: 2008-12-28 15:45:00
|Re: Converting a development team from FTP to a Versioning System||#10|
VisualSVNServer and TurtoiseSVN are the two programs I use, they are both well documented and it integrates so well with Windows Explorer and Visual Studio.
posted date: 2008-12-28 15:46:00
|Re: Converting a development team from FTP to a Versioning System||#11|
Is the answer to Q1 "Yes, they have never had a disaster"? Or is it "Yes; they have had disasters where they could not get back"? Sorry, the question is ambiguous.
posted date: 2008-12-28 15:54:00
|Re: Converting a development team from FTP to a Versioning System||#12|
The answer to your "multiple sites in main repository" question is "it depends". But I'd be extremely uncomfortable with a system where the developers did not have a good VCS in place for my site and my CMS. It has to be under VCS.
posted date: 2008-12-28 15:57:00
|select page: « 1 2 »|