代码推广：执行规则
所以这就是我们的问题：
我们有一个由开发人员组成的小团队，他们有自己的做事方式 - 我正在尝试规范一个流程，其中我们要求按以下顺序升级我们的代码：
本地沙箱>开发> UAT>分期>实时
开发人员在自己的沙箱上进行开发/测试，Dev 是它自己的沙箱，我们将使用它进行持续集成，UAT 是 IIS 中开发箱上的另一个站点，它使用我们的开发数据库。然后，我们升级到暂存，这是 Live 盒上 IIS 中的一个站点，并使用实时数据（就像实时一样，因此是暂存）。最后，我们提倡生活。
以下是我的一些问题：
1.) 这似乎是最佳实践吗？如果不是，需要采取哪些不同的做法？
2.) 如何向开发人员强制执行这些规则？开发人员经常为了节省时间而跳过一些步骤……这是不应该容忍的，如果可以物理强制执行，那就太好了。
3.) 我如何向业务组强制执行这些规则？该业务团队只是想快速推出功能。我们只在特定日期进行促销吗？
So here is our problem:
We have a small team of developers with their own ways of doing things-- I am trying to formalize a process in which we are required to promote our code in the following order:
Local sandbox > Dev > UAT > Staging > Live
Developers develop/test as they go on their own sandbox, Dev is its own box that we would use for continuous integration, UAT is another site in IIS on the dev box, which uses our dev database. We then promote to staging, which is a site in IIS on the Live box and using live data (just like the live, hence staging). Then, finally, we promote to live.
Here are a few of my questions:
1.) Does this seem to be best practice? If not, what needs to be done differently?
2.) How do I enforce the rules to the developers? Often developers skip steps in order to save time... this should not be tolerated and would be great if it could be physically enforced.
3.) How do I enforce these rules to the business group? The business group just wants to get features out FAST. Do we promote only on certain days?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对我来说听起来不错……我们没有我工作的区域。我们有DEV>质量保证>生产。
1）我不太确定什么是“最佳实践”，但你的设置对我来说似乎是一个非常好的实践。我唯一关心的是沙盒环境。是否能保证每天备份开发人员的代码？以防万一他们的机器严重崩溃？我不想失去好的开发代码。
2) 我们这里有一个“发布协调员”，他强制执行对 Sourcesafe 和 TFS 的访问，并控制对 QA 环境的访问，因此只有特定时间可用。
3) 业务测试人员也是如此，只不过他们的权力来自项目经理。 PM 有一份针对每个项目填写的文档，并指定了测试团队。
我们只在某些日子（每隔一个星期四）进行促销。然而，我们确实知道可能会出现紧急情况，并且我们会在需要时在休息日进行生产发布，但这些紧急情况会在事后记录并进行分析，以了解出了什么问题以及我们可以在哪些方面进行改进。
我想说，只要您的环境受到控制并记录下来，您就应该没问题。最好确保沙盒区域中的所有内容都得到备份，并且一小群人控制对其他环境的访问。我还建议您保留有关“安全”环境的来来去去的良好文档，以防万一出现问题，您可以通过日志回溯并查看可能发生了什么或谁可能做了这件事，而不一定要指责但要回过头来说“你到底上传/更改了什么？”这样我们就可以看到可能是什么导致了这个问题。
祝你好运，
sounds like a good setup to me ... we don't have as may areas where I work. We have DEV > QA > Production.
1) I'm not exactly sure what "best practice" is, but your setup seems like a very good practice to me. My only concern would be in the Sandbox environment. Are there assurances that the developer's code is backed up daily? just in case their machine crashes hard? I'd hate to lose good dev code.
2) We have a "release coordinator" here who enforces access to Sourcesafe and TFS and also controls access to the QA environment so there are only certain times when they are available.
3) The same goes for the business testers except their authority comes through the Project Managers. The PM's have a document that gets filled out per project and testing teams are specified.
We do only promote on certain days (every other Thursday). However we do understand that there can be emergencies and we have done production releases on off days when the need calls for it, but those emergencies are documented after the fact and analyzed to see what went wrong and where we can make improvements.
I'd say as long as your environment is controlled and documented you should be fine. It would be good to make sure everything is backed up in the sandbox area and that a small group of people control the access to the other environments. I would also recommend you keep good documentation on the comings and goings of the "secured" environments, just in case something goes wrong you can backtrack through the logs and see what might have happened or who might have done it, not necessarily to point fingers but to go back and say "what exactly did you upload/change?" so we can see what might have caused the issue.
Best of luck to you,
Scott已经回答得很好了，所以我不再重复他的逻辑。他似乎错过了这一点：
问题是，您无法对业务组执行任何操作。只有他们的经理可以。
您（作为 IT 人员）可以做的就是与业务部门经理会面，并进行成本/收益分析。
理想情况下，错误应该是过去实际发生的事情，而不是理论上的事情:)
然后将其与具有适当流程和相关减速的相对微不足道的成本（只需进行一些估计，希望有业务用户的输入）进行比较。
基本上，您需要他们的支持，以说服他们不走捷径符合他们的利益。
Scott already answered pretty well, so i won't repeat his logic. The one he seems to have missed was:
The problem is, you can not enforce anything on the business group. Only their managers can.
What you (as IT) can do is meet with the business side managers, and lay out the cost/benefit analysis.
Ideally, the bug would be something which actually happened in the past instead of a theoretical thing :)
Then compare that with the relatively insignificant (just make some estimates, hopefully with business user's input) cost of having proper process and associated slowdowns.
Basically, you need their buy-in, to convince them it's in their interest to not cut corners.
我们的店里也有类似的设置。我们通过使用不同的物理机器以及谁可以通过密码进行访问等来强制执行此操作。我在自己的 VPC 上进行本地开发，然后签入代码。就我而言，这就是结束。另一个人可以访问他根据需要运行构建的开发框，他无权访问“实时”框，另一个人可以。此人可以访问“开发”框和“实时”框，这样他就可以在需要时进行紧急部署等。一旦构建进入开发阶段并经过测试，只有这样，“实时”构建才算完成。
We have a similar setup at my shop. We enforce this by using different physical machines and who has access via passwords, etc. I develop locally on my own VPC, then check the code in. That is the end of it as far as I am concerned. Another person has access to the dev box where he runs builds as needed, he does not have access to the "live" box, another person does. This person has access to both the "dev" box and the "live" boxes--this way he can do an emercency deploy etc. if needed. Once a build has gone to dev and been tested, then, and only then, is a "live" build done.