Convert development team from FTP to version control system

Question

I work in a small LAMP development studio where the idea is to just make the code and move on to the next item in the list.

The team works in Zend Studio 5.5, connected to the Live server via FTP or SFTP. What they like about this is the speed at which they deploy the code (from the moment it changed only live code).

But of course, this is not good for many obvious reasons.

I would like to move them to a version control system (CVS, SVN or any other tool), but the trick is not my senior, so I need a carrot to start using it.

What settings will I need to build on my machine so that they can be encoded as usual?

What I would do is create this installation on my machine and then show it.

I know this is unusual, but it has turned into my passion to change my mindset from just breaking the code to structure and elegance. Thanks.

UPDATE (for Jonathan Leffler's answer):

• Yes
• Not
• Yes they really do

The question is also, does the studio make a centralized CMS system located on hundreds of sites, do they need to modify individual sites if the sites will be in the main composition or in their own?

Answer 1

Questions:

• You (they) never had a disaster when you (they) needed to go back to the previous version of the website, but failed because they broke it?

• Do they use a web server to test changes?

• Surely they don't change the code on the production server without any testing somewhere?

I suspect that the answer to the first question is: “Yes (they had disasters),” and the second “no,” and I hesitate to guess the answer to the third (but from his sounds the answer may be “yes, they really do”). If this is correct, I admire their bravado and wonder that they are never mistaken. I would never risk making changes directly to the website live.

I would recommend using a version control system or VCS (any VCS) yourself. Design wrinkles for the code you need, and develop a smooth distribution that makes it easy (possibly using SFTP) to distribute VCS code to a website. But they also show that preserving previous versions has its merits - because you can restore who did what when. To get started, you may need to download the current version of any page (file) you need to work in and put this latest version into VCS before you start changing the page because someone else can change it since it was the last times updated in your main repository. You can also do daily “cleanup” of files to get current versions and track changes. You would not have a “who”, and definitely “when” (better than the next day), and “why,” but you would have a (cumulative) “what” of the changes.

---

In response to the comments in the question, Olafur Vaaj explained that they had disasters due to the lack of VCS.

This usually makes life easier. They have gone astray; they could not break the deadlock - they probably annoyed customers, and they should have been incredibly annoyed with themselves. VCS greatly facilitates recovery from such errors. Obviously, for any given custom site, you need a (central) backup of the "correct" or "official" version of this site, available on VCS. I would probably choose a single repository for all clients using VCS, which has good support for branching and merging. This can be tricky at first (as long as people get used to using VCS), but they probably lead to better results in the long run. I would seriously consider using modern distributed VCS (e.g. git ), although many people use SVN too (even though it is not a distributed VCS).

Answer 2

you can use the svn turtle client to create and work with the repository on your local machine on some other file path, then your working path will be ...

perhaps try to customize and use this for yourself and show them what he can do for you. Another interesting thing may be related to installing trac ( http://trac.edgewall.org/ ) on your server if you have access and privileges for this, or maybe in some virtual machines on your own development machine. you can map trac to your svn and get svn changes in the web interface that you can show to the project manager. maybe it will fall, because it can easily see code changes through the web interface. Of course, you can only do this with the apache + svn module, but this is better, since it offers a way to sell tickets and roadmaps (steps and things that managers can dig: o)) ..

good luck anyway :). at least use it for your work on your local machine, as it will only be profitable for you.

Answer 3

You can install SVN on your local system for demonstration. There are some tools for integrating Zend and Eclipse into SVN. I think that in addition to demonstrating SVN, you should probably give them an idea of ​​some of the benefits it will bring (probably during the demonstration).

Follow this link for some ideas: Do I really need version control?

Answer 4

Here is one trick everyone will love:

I enable this “plugin” on most of my production sites: Of course, you need to create a limited privilege svn account for this, and svn must be installed on the server.

echo(' updating from svn<br>' ); $username = Settings::Load()->Get('svn','username'); $password = Settings::Load()->Get('svn','password'); echo(" <pre>" ); $repos = Settings::Load()->Get('svn' , 'repository'); echo system ("svn export --username={$username} --password {$password} {$repos}includes/ ".dirname(__FILE__)."/../includes --force"); echo system("svn export --username={$username} --password {$password} {$repos}plugins/ ".dirname(__FILE__)."/../plugins --force"); die(); 

Make sure you put this behind the .htpasswded site, and make sure you are not updating the "production settings" from SVN. Et voila, you update your complete code base with one HTTP request to your site :) SVN automatically overwrites the files, there are no hidden files or folders and is easily adapted to update or return to a specific version. Now all your team needs is to commit their SVN repository, run this piece of code in a test environment, make sure that everything works, and then run it during production :)

Answer 5

Olafur, you mentioned that "the studio creates a CMS system hosted on hundreds of sites." This in itself may be the carrots you need. If a team often deploys updates to these hundreds of sites, then using branches within the version control system can make this process much easier for everyone. This can be a huge time saver and, in so doing, will provide an incentive for people to learn about version control.

It seems that these sites are connected to each other - custom versions of the same CMS. In this case, you must put all the sites in the same repository, in addition to the unconfigured CMS product. You can then configure them as branches of the same central product. If you use separate repositories, there are no easy ways to create branches to bind settings to the main product. (I think you can do it with Subversion, and most likely with others, but it's complicated and unnecessary if all the developers work for the same organization.)

Answer 6

VisualSVNServer and TurtoiseSVN are the two programs that I use, they are well documented and integrate well with Windows Explorer and Visual Studio.

Answer 7

Make part of the deployment of the automated build process so that the developer does not worry about it. Use the "threads" to continue working in the development, production, and production areas, and then the automated processes deploying the latest development, qa, and release environments.

Answer 8

Just put, i.e. SVN in the middle.

The development team put new material into subversive activities, and then you have a script that exports material from svn and sends it to the web server.

This is very close to how they work today, but every little change was recorded in subversive activities, so if lightning strikes, you can quickly return everything on time.

/ Johan