关于建立版本控制系统的想法
我的任务是为我们的网络开发人员设置版本控制。 我之所以选择这个软件是因为我们已经有其他非 Web 开发人员在使用它，它是 Serena PVCS。
我很难决定如何设置它，所以我将描述我们的系统中的开发是如何发生的，并希望它会引发一些关于如何最好地做到这一点的讨论。
我们有 3 台服务器：开发服务器、UAT/登台服务器和生产服务器。 Web 开发人员只能在开发服务器上编写和测试他们的代码。 一旦他们编写了代码，他们必须经过认证过程才能将代码转移到 UAT/Staging，然后在代码经过彻底测试后，将其转移到生产。
似乎让开发人员对他们不断更改和测试的开发代码使用版本控制会很烦人。 通常，一次只有一名开发人员处理一个模块，因此覆盖其他人的工作的风险（如果有的话）也不大。
我的想法是让他们只在准备好进入 UAT/Staging 时才使用版本控制。 这使得他们无需不断检查代码即可进行开发和测试。
然后，认证小组可以使用版本控制来帮助查看对模块进行了哪些更改，并确保他们始终从开发人员那里获得最新版本以发布到 UAT/Staging（现在我们依赖于开发人员 zip）更新他们更改的文件并通过网络请求系统上传）。
这将处理开发的文件方面，但使整个数据库方面不受版本控制。 这是我需要考虑的其他事情......
任何想法或想法将不胜感激。 谢谢。
I've been tasked with setting up a version control for our web developers. The software, which was chosen for me because we already have other non-web developers using it, is Serena PVCS.
I'm having a hard time trying to decide how to set it up so I'm going to describe how development happens in our system, and hopefully it will generate some discussion on how best to do it.
We have 3 servers, Development, UAT/Staging, and Production. The web developers only have access to write and test their code on the Development server. Once they write the code, they must go through a certification process to get the code moved to UAT/Staging, then after the code is tested thoroughly there, it gets moved to Production.
It seems like making the Developers use version control for their code on Development which they are constantly changing and testing would be an annoyance. Normally only one developer works on a module at a time so there isn't much, if any, risk of over-writing other people's work.
My thought was to have them only use version control when they are ready to go to UAT/Staging. This allows them to develop and test without constantly checking in their code.
The certification group could then use the version control to help see what changes had been made to the module and to make sure they were always getting the latest revision from the developer to put up on UAT/Staging (now we rely on the developer zip'ing up their changed files and uploading them via a web request system).
This would take care of the file side of development, but leaves the whole database side out of version control. That's something else that I need to consider...
Any thoughts or ideas would be greatly appreciated. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用源代码管理并不麻烦，它是一个工具。 在使用新的 API 和库时，分支和标记的好处是非常宝贵的。
顺便说一句，几个月前，开发人员的一台机器发生故障并丢失了所有最新源代码，我们询问他上次向源代码管理提交代码是什么时候，那是两个月前的事了。 有时，当您达到里程碑时用它来备份东西就很好了。
我通常每周进行几次源代码控制，具体取决于我是否达到了一个好的停止点并且我即将转向不同的或更大的事情。
Using source control isn't any annoyance, it's a tool. Having the benefits of branching and tagging is invaluable when working with new APIs and libraries.
And just a side note, a couple of months back one of the dev's machine's failed and lost all his newest source, we asked when the last time he committed code to the source control and it was 2 months. Sometimes just having it to back up stuff when you reach milestones is nice.
I usually commit to source control a couple of times a week, depending if I've hit a good stopping point and I'm about to move on to something different or bigger.
继最后两个优点之后，我还会询问其他非 Web 开发人员他们正在使用什么开发流程，这样您就不必创建新的流程。 他们还会遇到您的环境中出现的许多问题，包括使用相同操作系统的技术问题以及设置和管理问题。
Following on from the last two good points I would also ask your other non-web developers what developmet process they are using so you won't have to create a new one. They would also have encountered many of he problems that occur in your environment, both technical using the same OS and setup and managerial.
我不会将源代码控制视为烦恼。 原因请参见尼克斯的回答。
如果我是你，我不会自己决定这件事，因为这不是一个
在某些服务器上设置版本控制软件的问题但是
更改和改进开发程序的问题。
在您的情况下，可能值得解释和讨论发布分支
与您的开发人员一起并提供质量保证。
这意味着您的开发人员决定将哪些功能包含到版本中
当登台工作人员忙于测试源的“登台”分支时，
您的开发人员已经可以在不干扰暂存团队的情况下开发下一个版本。
您还可以考虑功能分支，这意味着网站的每个特定新功能都有一个新分支。 如果实现了该功能，这些分支将被合并回来。
但再次强调：请确保您的团队同意新的开发流程。 否则，您会浪费时间来设置版本控制系统。
该过程至少应包括：
I would not treat source control as annoyance. See Nicks answer for the reasons.
If I were You, I would not decide this on my own, because it is not a
matter of setting up a version control software on some server but
a matter of changing and improving development procedures.
In Your case, it might be worth explaining and discussing release branches
with Your developers and with quality assurance.
This means that Your developers decide which feature to include into a release
and while the staging crew is busy on testing the "staging" branch of the source,
Your developers can already work on the next release without interfering with the staging team.
You can also think about feature branches, which means that there is a new branch for every specific new feature of the web site. Those branches are merged back, if the feature is implemented.
But again: Make sure, that Your teams agreed to the new development process. Otherwise, You waste Your time by setting up a version control system.
The process should at least include:
我用过Serena，确实很麻烦。 除了塞琳娜在签入签出流程之上增加的工作流程开销之外，除了最简单的任务之外，做任何事情都是一种真正的痛苦。
在 Serena ChangeMan 中，本地计算机上的所有代码都通过中央服务器进行管理。 这是一个非常糟糕的设计。 这意味着通常由开发人员完成的许多日常分支维护工作必须通过拥有管理员权限的人来完成，这使得该人 1) 成为瓶颈，2) 因他们的工作而感到痛苦。
集中管理还严格限制了开发人员可以在自己的机器上使用代码执行哪些操作。 例如，如果您想在您的机器上本地创建代码的第二个副本，只是为了进行快速测试或其他什么，您必须让管理员在您的机器上设置第二个存储库。 当你像这样限制开发人员时，你就限制了团队的生产力和创造力。
此外，这些工具很糟糕，用户界面也很糟糕。 而且你永远找不到已经接受过使用它培训的开发人员，因为它太晦涩难懂了。
因此，如果其他球队说你必须使用塞雷娜，请予以反击。 那个产品太糟糕了。
I have used Serena, and it is indeed an annoyance. In addition to the unpleasantness of the workflow overhead Serena puts on top of the check in-check out process, it is a real pain with regard to doing anything besides the simplest of tasks.
In Serena ChangeMan, all code on local machines is managed through a central server. This is a really bad design. This means a lot of day-to-day branch maintenance work that would ordinarily be done by developers has to go through whomever has administrator privileges, making that person 1) a bottleneck and 2) embittered because they have a soul-sucking job.
The centralized management also strictly limits what developers are able to do with the code on their own machine. For example, if you want to create a second copy of the code locally on your box, just to do a quick test or whatever, you have to get the administrator to set up a second repository on your box. When you limit developers like this, you limit the productivity and creativity of your team.
Also, the tools are bad and the user interface is horrendous. And you will never be able to find developers who are already trained to use it, because its too obscure.
So, if another team says you have to use Serena, push back. That product is terrible.