将开发团队从FTP转换到版本控制系统

6
我在一家小型的LAMP开发工作室工作,他们的想法是只需完成代码并继续进行下一个任务。团队使用Zend Studio 5.5通过FTP或SFTP连接到实时服务器。他们喜欢这种方式的原因是可以快速部署代码(因为只需修改实时代码)。
但是,显然这样做有很多明显的问题。我想将他们转移到版本控制系统(CVS、SVN或任何其他工具),但问题是,我不是他们的高级员工,所以我需要一个奖励来鼓励他们开始使用这个系统。
我需要在他们的机器上建立哪种设置,才能让他们像往常一样编写代码?
我会在我的机器上创建这个设置,然后向他们展示。虽然这有点不寻常,但我已经热衷于改变他们的思维方式,从简单的代码编辑转变为结构化和优雅的开发方式。谢谢。
更新(针对Jonathan Leffler的答案):
  1. 是的
  2. 不是
  3. 是的,他们确实需要
另外一个问题是,该工作室制作了一个集中式CMS系统,托管在数百个站点上,他们需要修改各个站点,那么这些站点应该在主仓库中还是在它们自己的仓库中?

Q1的答案是“是的,他们从未遭受过灾难”吗?还是“是的,他们曾经遇到过无法恢复的灾难”?抱歉,这个问题不够明确。 - Jonathan Leffler
你关于“主仓库中有多个站点”的问题的答案是“这要看情况”。但是,如果开发人员没有为我的网站和我的CMS建立良好的版本控制系统,我会感到非常不舒服。它必须在版本控制系统下。 - Jonathan Leffler
答案是肯定的,他们曾经遭受过灾难。 - Ólafur Waage
8个回答

7

问题:

  1. 你(或者他们)是否曾经遇到过灾难,需要恢复到网站的以前版本,但是因为已经损坏而无法恢复?

  2. 他们是否使用暂存服务器来测试更改?

  3. 他们肯定不会在生产服务器上修改代码而没有任何测试吧?

我怀疑第一个问题的答案是“是的(他们曾经遇到过灾难)”,第二个问题的答案是“否”,而对于第三个问题,我不确定(但是从听起来的情况来看,答案可能是“是的,他们真的这样做了”)。如果我的猜测是正确的,那么我很佩服他们的勇气,并且惊讶于他们从未犯过错误。我从不冒险直接在现场网站上进行更改。

我建议您自己使用版本控制系统或VCS(任何VCS)。解决您所关注的代码中的问题,并开发出使其易于分发的流畅分发方式(可能仍然使用SFTP)以将VCS代码分发到网站。但是还要表明保留先前版本具有其优点-因为您可以恢复谁在何时做了什么。首先,您可能需要下载您需要处理的任何页面(文件)的当前版本,并将该最新版本放入VCS中,然后再开始修改该页面,因为其他人可能已经自上次更新主存储库以来对其进行了修改。您可能还想每天“刮取”文件以获取当前版本-并跟踪更改。您将没有“谁”,也不会确切地知道“何时”(比最近一天更好),也不知道“为什么”,但是您将拥有更改的(累积)“内容”。


在回答问题的评论中,Ólafur Waage澄清说,由于缺乏VCS,他们遭受了灾难。

通常情况下,这会使生活变得更加容易。他们犯了错;他们无法撤消这个错误-他们可能有恼怒的客户,他们应该非常生气。 VCS使从此类错误中恢复变得更加容易。显然,对于任何给定的定制站点,您需要在VCS中提供“正确”或“官方”版本的(中央)备份。我可能会为所有客户选择一个单一的存储库,并使用具有良好分支和合并支持的VCS。这可能在一开始时更难处理(当人们开始使用VCS时),但长期来看可能会产生更好的结果。我认真考虑使用现代分布式VCS之一(例如git),尽管许多人也使用SVN(即使它不是分布式VCS)。


2

你可以使用Tortoise SVN客户端在本地机器上创建和处理存储库,该存储库位于与您的工作路径不同的文件路径上....

也许尝试为自己设置并使用它一段时间,然后展示给他们看它能够为你做些什么。另一个酷炫的东西可能是在您有权访问的服务器上安装Trac(http://trac.edgewall.org/),或者在自己的开发机器上的某个虚拟机中安装Trac。您可以将Trac映射到您的SVN,并在Web界面中获取SVN更改,您可以向项目经理展示这些更改。也许他会被这种通过Web界面轻松查看代码更改的方式所吸引。当然,您只能使用Apache + SVN模块来完成此操作,但是这种方法更好,因为它提供了通向票务和路线图(里程碑和其他经理可能感兴趣的东西:o))的路径。

无论如何祝你好运:)。至少,在本地机器上使用它来工作,对您来说只有收益。


我喜爱这个软件,观察了一段时间,两周前刚刚设置好了,自那以来我就是最开心的人了... :)。它简单、实用、易于使用... 并且在0.11.x版本后易于安装。我在VM中安装了干净的Debian系统,并让它运行起来,不到半小时就完成了。 - zappan

2
您可以在本地系统上安装SVN进行演示。有一些工具可以将Zend和Eclipse集成到SVN中。除了演示SVN之外,我认为您可能还应该向他们介绍它带来的一些好处(可能在演示期间)。请访问此链接获取一些想法:Do I Really Need Version Control?

2

这里有一个大家都会喜欢的技巧:

我在大多数生产网站中都包含了这个“插件”: 当然,首先需要创建一个有限权限的机器人svn账户,并在服务器上安装svn。

    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();

确保你将此代码放在有.htpasswd保护的网站后面,并确保不要从SVN更新“生产设置”。 然后,您只需通过一个HTTP查询即可更新您的整个代码库 :) SVN会自动覆盖文件,没有隐藏的文件或文件夹留下来,非常容易适应更新或还原到特定版本。 现在,您的团队只需要提交到他们的SVN存储库,运行此代码片段在测试环境上进行测试,确保一切正常,然后在生产环境上运行即可 :)


1
Ólafur,你提到“工作室制作了一个CMS系统,托管在数百个网站上。”这本身可能就是你需要的诱因。如果团队经常向这些数百个网站部署更新,则使用版本控制系统内的分支可能会使这个过程对每个人都更加容易。这可能会节省大量时间,从而为人们学习版本控制系统提供激励。
听起来这些网站都是相关的 - 定制版本的同一CMS。在这种情况下,除了未定制的CMS产品之外,您应该将所有站点放入同一个存储库中。然后,您可以将它们全部配置为同一中央产品的分支。如果使用单独的存储库,则没有简单的方法来创建分支以将自定义与主要产品相关联。(我认为您可以使用Subversion和其他大多数方式来实现,但如果所有开发人员都为同一组织工作,则这是复杂且不必要的。)

抱歉,我应该说明一下 CMS 本身是集中化的,但是你说得对,因为每个站点内部有一些元素我希望能够更改。 - Ólafur Waage

0

VisualSVNServer和TurtoiseSVN是我使用的两个程序,它们都有良好的文档,并且与Windows Explorer和Visual Studio集成得非常好。


0

将部署过程作为自动化的“构建”过程的一部分,使得没有开发人员需要担心它。使用“流”将工作保留在开发区域、QA区域和发布区域,然后有自动化流程来部署最新的开发、QA和发布环境。


0

只需将SVN放在中间。

开发团队将新内容放入子版本控制系统,然后您有一个脚本从svn导出内容并将其发送到Web服务器。

这与他们今天的工作方式非常接近,但是每个小变化都已记录在子版本控制系统中,因此如果遭遇灾难,可以非常快速地回溯所有内容。

/约翰


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接