我需要一些关于我们的工作stream程与其他人相比的一些想法。 我们有一个开发人员在我们的营销网站工作，她知道如何编码，这是关于它（没有源代码控制经验，没有命令行….没有）。 过去，开发人员一直使用Eclipse直接在服务器上编辑所有内容。 意思是，如果她发了一些东西并保存起来，那么这个世界是可以看到的。
因此，在几十次“事故”之后，我一直致力于创build一个新的工作stream程，而不仅仅是在活动服务器上编辑文件。 这是我到目前为止..
带有营销库的Subversion服务器
一个“生产”虚拟机，主要的营销网站在我们说话的时候就在网上。
一个“暂存”虚拟机，允许她在上传任何更改到“生产”之前，在相同的环境中查看更改
一个脚本，允许她将最新的SVN标签同步到这些服务器。
为了保持这两个服务器的完整性，我想制作第三个“沙盒”服务器。 这将是另一个虚拟机，从“分段”服务器复制。 有了这个服务器，她可以尝试代码，尝试新的东西，而不用担心制作分段或生产服务器FUBAR。
当我提出这个计划的时候，我从很多方面得到了很多抱怨和呻吟，这些工作为她创造了多less工作。 stream程将是：
Edit Code in new branch > sync to SANDBOX. Repeat until satisfied. Merge changes to Trunk, create a new a tag from trunk and sync to STAGING. Do a QA check. If everything looks ok, sync to PRODUCTION. （我对这个过程的新观点非常开放）
正如从一个从来没有使用过源代码控制的用户所期望的，用来编辑文件，按ctrl + s来保存，然后刷新浏览器，这是一场噩梦。 我很想find一些中间的地方，但是如果我们要保持沙盒/舞台/制作的安排，那么就很难做到这一点。
什么为你们工作？
你的计划基本上是合理的。
强制开发者的工作。 无论如何，请将该开发者发送给培训机构或当地的开发小组，以获得成功。 说服你的共同老板的需要。 （如果你必须使用'转向恶意'或'遗漏东西'的scheme，或简单的'networking服务器被黑客破坏'的情况。虽然我会build议任何新的项目，托pipe在私人服务器或付费的github帐户ThinkLikeAGit ， Roger Dudler的“Git – The Simple Guide”和“ Git for Ages 4 and Up （ 直接到video ）都非常棒。
我更喜欢Master是一个主要的开发分支，一个将被部署用于testing的Staging分支，以及一个Production分支（或者在部署提交上带有版本号的Staging分支上的标签）。 我也喜欢分支function的想法。 询问100位开发人员他们是如何喜欢他们的源代码控制的，你将得到65个答案。
我非常不喜欢和build议师父是“生产”部门。 一个新手的错误（每个人都犯的错误）是犯了错误的分支。 不要让生产成为默认分支。
是的，开发人员疯狂的地方。 做你想做的; 这是你的家，沙箱，不pipe。 开发应该发生在本地机器上，但是这个环境看起来像是生产环境，但却是灵活的发展。 虚拟机在基本状态（每当产品更新时）都有快照。
一旦开发人员对自己的代码感到满意，就会将其部署到分段服务器。 这是一个完全匹配生产的服务器，但URL除外。 （她的代码应该使用相对path，而不是网站的实际名称。）
这是踢球者：一旦她满意现场准备好生产，她就会停下来。 她没有部署到Prod（还）。现在发生了一个未知的QA过程。 有人要注意错误（至less对这个新代码应该做什么有一个概述性的理解），在Staging中检查这个站点。 （你是创造者，对自己的许多错误一无所知，使你无法validation自己的工作。）他们testing网站，确保问题得到解决，没有什么新东西被打破。
我无法强调这一点：开发人员不做QA！ 她应该确保她的网站在通过质量检查之前没有明显的破损，但是她不会批准生产。 （首先，她performance出对最佳做法缺乏了解，而错误则表明出于正当理由存在最佳做法。）
正在进行质量保证的人员的职业声誉受到威胁; 如果把一个错误推给了Prod，那么他们的批准就会发生。
如果QA发现错误，他们将被识别给开发人员解决。 这个过程重新进行，并通过质量保证审查和签署完成。
就我个人而言，我是开发者自己部署的粉丝。 他们得到即时反馈，知道任务已经完成，并且不让其他人进行部署，如果出现问题，他们会感觉到更大的主人翁感。 （说“它在我的机器上工作”应该是死罪。）
最重要的部分是回购的东西得到部署。 没有“一次性”牛仔编码的变化。
一旦QA签字发生，代码最终可以推送到Prod。 这取决于你和你的部署谁的部署; 它可以是编码人员，也可以是质量保证人员。 如果部署没有完全执行，则会返回给开发人员。
事情的方式现在显然是行不通的。 推动制定这样的强制性公司政策（当然，如果你同意的话），并且坚持就业。 它可能会为您的可怜的开发人员采取更多的步骤 ，但对于公司来说，这样做的工作量更less ，尤其是在发生错误时。 更不用说在生产Web服务器之外拥有已知良好的代码状态的安全网。
我不知道你在为部署做什么，但应该是一步到位或者没有步骤。
“一步部署”的一个示例是您在Prod服务器上运行的脚本（也应该是Staging服务器，Devl也是如此），从您的repo中拉下相应的分支并重新启动所需的Web服务。
无步骤部署的一个例子是一个cron，它监视相应的分支，并在更新分支时自动更新代码。
如果她直接在SANDBOX服务器上工作，但要将文档根目录本身作为“营销”存储库的工作副本，那么她在编辑 – 刷新周期中唯一需要担心的额外事情就是偶尔签入。 她很快就会想，如果没有VC，她是如何做到的。 标签和分支的价值可能难以跨越。 通过编写脚本来尽可能简化部署到分段和生产。
这里缺less的一部分基本上是如何pipe理和执行一个版本，和/或一个正式的变更控制机制。 我并不是build议有实际的应用程序，但应该有一个stream程，其中包括：
理想情况下，除开发人员或执行更改的人员之外，还需要执行validation以及描述validation的文档或清单。
时间窗口将事先商定，通常会阻止在明显不利的时间做某事。 （谁星期五推码？）
我会小心不要阻碍这个过程。 如果他们想每天推送代码，系统不应该成为阻碍事情完成的障碍。