我需要一些关于我们的工作流程与其他工作流程相比如何的想法。我们只有一名开发人员负责我们的营销网站，她知道如何编写代码，仅此而已（没有源代码控制经验，没有命令行……什么都没有）。过去，开发人员总是使用 Eclipse 直接在服务器上编辑所有内容。这意味着，如果她手误操作并保存了它，那么全世界都可以看到它。
因此，在经历了数十次“失误”之后，我被要求创建一个新的工作流程，这比仅仅编辑实时服务器上的文件更合适。以下是我目前所得到的。
带有营销存储库的 Subversion 服务器
正如我们所说，一个“生产”虚拟机，其主要营销站点已在网络上启动。
一个“暂存”虚拟机，允许她在我们将任何更改上传到“生产”之前查看相同环境中的更改
一个脚本，允许她将最新的 SVN 标签同步到其中任一服务器。
为了保持这两台服务器的完整性，我想创建第三台“沙盒”服务器。它将是另一台虚拟机，从“暂存”服务器复制而来。有了这个服务器，她可以试验代码，尝试新事物，而不必担心让暂存或生产服务器陷入混乱。
当我提出这个计划时，我收到了来自多方的抱怨和牢骚，抱怨这给她带来了太多工作。流程如下：
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 保存然后刷新浏览器的人来说，这简直是一场噩梦。我很想找到一些折衷方案，但如果我们要保留 Sandbox/Staging/Production 设置，那就很难做到了。
什么对你们有用？
答案1
你的计划大体上是正确的。
源代码控制：
让开发人员的工作必须具备这一点。一定要让开发人员参加培训或参加本地开发小组的培训。说服你们共同的老板相信这一点。（如果必须，请使用“变成恶意的”或“遗漏了某些内容”的场景，或者使用简单的“网络服务器遭到黑客攻击和破坏”的场景。尽管我建议任何新项目都使用 git，托管在私人服务器或付费的 github 帐户上。 像思考一样思考，Roger Dudler 的“Git - 简单指南”， 和 ”Git 适合 4 岁及以上儿童（直接视频) 都很棒。
我更喜欢 Master 是主要开发分支、用于部署测试的 Staging 分支和 Production 分支（或 Staging 分支上的标签，在部署的提交上带有版本号）。我还喜欢功能分支的想法。询问 100 位开发人员他们喜欢他们的源代码控制吗，你会得到大约 65 个答案...
我非常不喜欢并且不建议将 Master 设为“生产”分支。新手会犯的一个错误（每个人都会犯）就是提交到错误的分支。不要让生产成为默认分支。
开发服务器：
是的，这是开发人员疯狂的地方。做任何你想做的事；这是你的家、沙盒，随便什么。开发应该在本地机器上进行，但这是一个看起来像生产的环境，但有疯狂的灵活性。建议使用在基础状态（以及 Prod 更新时）拍摄快照的 VM。
临时服务器：
一旦开发人员对代码感到满意，它就会被部署到临时服务器。这是一个除了 URL 之外与生产完全匹配的服务器。（她的代码应该使用相对路径，而不是站点的实际名称。）
关键在于：一旦她确信网站已准备好投入生产，她就会停止。她不会部署到生产环境（暂时不会）。现在会发生一个前所未有的 QA 流程。一个善于发现错误的人（并且至少对新代码应该做什么有一个总体了解）会审查 Staging 中的网站。（你，创建者，对自己的许多错误视而不见，这让你没有资格验证自己的工作。）他们会测试网站，确保问题得到修复，并且没有出现任何新问题。
我再怎么强调也不为过：开发人员没有做 QA！她应该确保她的网站在交给 QA 之前没有任何明显的问题，但她没有批准将其用于生产。（首先，她表现出对最佳实践缺乏理解，而错误表明最佳实践的存在是有正当理由的。）
负责 QA 的人员的专业声誉岌岌可危；如果将错误推给生产部门，那么是他们的认可导致了错误发生。
如果 QA 发现错误，则告知开发人员进行修复。流程重新开始，并由 QA 进行审查和签字。
就我个人而言，我支持开发人员自己进行部署。他们可以立即获得任务完成的反馈，而且通过不让其他人进行部署，如果出现问题，他们会有更强的主人翁意识。（说“它在我的机器上运行良好”应该是死罪。）
最重要的部分是 repo 中的内容会被部署。不存在“一次性”的牛仔编码更改。
生产：
一旦 QA 签字通过，代码就可以最终推送到 Prod。部署由你和你的组织决定；可以是程序员，也可以是 QA 人员。如果部署没有完全执行，则将返回给开发人员。
综上所述：
现在的做法显然行不通。推动制定类似这样的强制性公司政策（当然，如果你同意的话），并将遵守该政策作为就业的条件。这可能会让更多步骤对于可怜的开发人员来说，这是更少的工作，尤其是在错误上线时。更不用说在生产网络服务器之外拥有已知良好状态的代码的安全网了。
可选奖励积分
我不知道您在做什么部署，但它们应该是一步到位或无步骤的。
一步部署的一个示例是在 Prod 服务器（也应该是 Staging 服务器和 Devl）上运行的脚本，该脚本从您的 repo 中提取相应的分支并重新启动所需的 Web 服务。
无步骤部署的一个示例是 cron，它监视适当的分支并在分支更新时自动更新代码。
答案2
如果她直接在 SANDBOX 服务器上工作，但将文档根目录本身设为“营销”存储库的工作副本，那么她在编辑刷新周期中唯一需要担心的额外事情就是偶尔签入。她很快就会想知道如果没有 VC 她会怎样。标签和分支的价值可能更难传达。通过编写脚本，使部署到 STAGING 和 PRODUCTION 尽可能简单。
答案3
这里缺少的部分内容从根本上是如何管理和执行发布，以及/或正式的变更控制机制。我并不是建议有一个实际的应用程序，但应该有一个包括以下内容的流程：
- 传达变更（变更的日期/时间以及变更的内容）
- 风险或影响潜力（低/中/高）
- 变化的时间窗口
- 系统不可用的时间窗口
- 如有必要，独立人员可以使用这些指示来执行变更
- 必要时撤销更改的说明
- 谁在执行变更以及他们的联系信息
- 谁在验证变更以及他们的联系信息
- 验证的截止日期，如果验证未完成，则应撤消更改
理想情况下，除了开发人员或执行更改的人员之外，还会有人执行验证，并提供描述验证的文档或清单。
时间窗口会提前商定，这通常可以避免在明显不好的时间做某事。（谁会在星期五推送代码？）
我会小心谨慎，不要妨碍这个过程。如果他们想每天推送代码，那么系统不应该成为完成任务的障碍。