多开发人员设置，为每个开发人员提供 SVN-VC 和远程测试服务器。最佳实践？
我想就具有以下要求的专业开发设置提供一些意见。
- 多名 PHP 开发人员（例如 PHP）
- 每个开发人员属于一个小组
- 每个小组都有一名团队领导，负责委派任务
- 每个开发人员在一台 Windows 7 计算机上工作
- 并使用 NetBeans 或 Eclipse 进行开发
- 每个开发人员“拥有”一台虚拟测试服务器，其中他可以运行代码
- 使用的 VCS 是 SVN
- 有一个临时服务器，产品在发布/部署之前最终会在其中进行测试
我提供了一些具体的技术，不要太抽象，而且我也对具体建议感兴趣对于插件等。
在该设置中我想到了几个问题。
1）所以每个开发人员都会致力于 个人分支机构。
2) 该分支在工作副本中签出。
现在...这个工作副本是使用开发人员的 IDE 在 PC 上本地编辑的，并在服务器上执行/测试的。
在这种情况下，最好/通常的方法是什么？我的意思是 - 如何在服务器上获取编辑后的代码而不造成太多开销？
开发人员的本地磁盘上是否有代码？或者让 IDE 通过隧道或特定协议在远程虚拟服务器上写入会更好吗？
3）每天，开发人员都会将其工作提交到位于中央存储库中的个人分支中。
是否有关于存储库应该位于何处的最佳实践？一个单独的服务器？
4）然后，在开发人员完成他的任务后，他/她或团队领导将新代码合并到各自的主分支或主干中。
最令人困惑的部分是我在 2) 和 3) 之间写的内容。因为到目前为止我只使用本地服务器。例如，一台虚拟机的服务器运行位于共享文件夹中的代码，因此我可以直接编辑它。当服务器现在实际上是远程的时，我不确定如何有效地弥补差距。例如，高效意味着不必通过 FTP 手动上传。
也欢迎外部资源或书籍推荐。
编辑
我的问题是针对准标准/最佳实践。我认为这几乎是一个标准的开发场景，因此必须有一个“常用”解决方案。
编辑 2
好吧...让我们尝试一张图片： 
V 是一个或多个开发人员的虚拟测试服务器 D。 C 和 C' 是两个代码版本。它们应尽可能保持相同。
我想到了两种解决方案：
1：编辑C，然后将其上传到C'，然后执行C'，然后提交C。
2：不存在C。只是通过一些隧道技术编辑并执行和提交的C'。
我的直觉告诉我，这两种解决方案都是半最优的。那么什么是“专业”/最高效/最快/最方便/最无摩擦/最不易出错/最佳实践/行业标准？
有疑问吗？
I would like to have some input on how a professional development setup with the following requirements might look like.
- several PHP-developers (say PHP)
- each developer belongs to one group
- each group has one team-leader who delegates tasks
- each developer works on one Windows 7 machine
- and developes either with NetBeans or Eclipse
- each developer 'owns' one virtual test-server where he can run the code
- the VCS in use is SVN
- there is a staging server where the product is ultimately tested before it gets released/deployed
I gave some specific technology to not be too abstract and b/c I also would be interested in concrete suggestions for plug-ins etc.
There are several questions coming to my mind in that setup.
1) So every developer will work on
personal branch.
2) This branch is checked out in a working copy.
Now ... this working copy is edited locally on the PC with the dev's IDE and executed/tested on the server.
What would be in that case the best/usual way to do that? I mean - how do you get your edited code on the server without causing too much overhead?
Would the dev have the code on his local disk at all? Or would it be better to have the IDE write on the remote virtual server through a tunnel or via a specific protocol?
3) Every day a dev will commit his work into his personal branch which resides in a central repository.
Is there a best practice on where the repository is supposed to be located? A seperate server?
4) Then after a dev finished his task either s/he or the team-leader merges the new code into the respective main-branch or trunk.
The most confusing part is about what I wrote between 2) and 3). Because so far I only worked with a local server. For example a VM with a server running a code which is located in a shared folder so I will be able to edit it directly. I'm not sure how to bridge the gap efficiently when the server is now actually remote. Efficiently means not having to upload manually via FTP for example.
Also external sources or book recommendations are welcome.
edit
My question/s is/are aiming at a quasi-standard / best-practice. I think this is pretty much a standard development scenario so there must be a 'usual' solution.
edit 2
Okay ... so lets try with a picture:
V is the virtual test-server for one or more developers D. C and C' are the two code-versions. They should be kept as identical as possible.
Two solutions come to my mind:
1 : Edit C, then upload it to C', then execute C', then commit C.
2 : No C existant. Just C' which is edited through some tunnel technology and executed and committed.
My guts tell me both solutions are semi-optimal. So what would be "professional" / most efficient / fastest / most convenient / most friction-less / least error-prone / best practice / industry standard?
Any questions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
也许它没有太大帮助，但 GIT 听起来非常适合您的问题，我建议看看 GIT 功能。如果您有时间，请查看 Linus Torvalds 他关于 GIT 的自述。 http://www.youtube.com/watch?v=4XpnKHJAok8
Maybe its not of great help but GIT sounds like a perfect fit to your problems, i recommend to take a look to the GIT features. And if you got time check Linus Torvalds him self talking ablout GIT. http://www.youtube.com/watch?v=4XpnKHJAok8
您所描述的标准程序或多或少是相同的。我也为我的团队采用了这种方法。也可以称为分阶段应用程序开发。
我是这样做的，我使用远程 SVN 主机（例如：assembla.com、unfuddle.com）来存储我的所有代码。我的团队成员将信息存储在这些远程 svn 服务器上。您还可以购买 VPS 并在那里设置 SVN，并使用相同的方法。
最佳实践是在本地测试并尽可能多次提交，但每次提交都必须解决问题或包含添加任何新功能的重要部分。
一旦每个人都完成提交，首席开发人员就可以使用 PuTTY 等工具通过 SSH 登录登台服务器。第一次，首席开发人员必须将代码检出到代码所在的文件夹中。在此阶段，如果多个开发人员编辑文件的同一段，则可能会出现文件冲突。首席开发人员应首先解析代码，然后继续结账。一旦签出，首席开发人员只需在登台服务器上执行 svn 更新即可使代码保持最新。
基本思想是让代码在本地设置上运行，然后提交并更新暂存以在模拟场景中测试应用程序，然后将其提交到实时站点。
这里有很多“如果”和“但是”，这需要我写一章来讨论:)，但简而言之，这就是热情。
工具（您可以用来在此设置下工作）：
- 乌龟SVN管理器
- 腻子
- NetBeans
希望它有帮助:)
The standard procedure as you describe is more or less the same. I also you this approach for my team. It can also be called staged application development.
Here is how I am doing it, I use a remote SVN host (ex: assembla.com, unfuddle.com) to store all my codes. My team members store the information there on these remote svn servers. You can also buy an VPS and setup SVN there and user the same approach.
Best practices is to test locally and commit and commit as many times as you can but every commit must solve a problem or include a significant segment that adds any new feature.
Once the commit is done by everyone the lead developer then can login to the staging server via SSH using tools like PuTTY. First time the lead developer has to checkout the code into the folder where the codes are to be located. During this phase file conflict may arise if multiple developers edits same segment of a file. The lead developer should then resolve the code first and then proceed with the checkout. Once checked out, there onwards the lead developer will only need to do a svn update on the staging server to make the code up to date.
Basic idea is to get the code working on local setup then commit and update the staging for testing the application on a simulated scenario and then commit it to the live site.
There are a lot of if's and but's here which will need me to write a chapter on :) but in short this is the zest.
Tools (you can use to work under this setup):
- Tortoise SVN Manager
- PuTTy
- NetBeans
hope it helps :)
我不喜欢与个人分支机构合作。我使用 ClearCase 工作了近 15 年，尽管 ClearCase 可能比大多数软件更好地处理个人分支，但这仍然是一个很大的痛苦。更糟糕的是，个人分支鼓励人们直到最后一刻才提交工作——通常是主要版本发布前的一两天。
出于这个原因，为了迫使开发人员彼此保持正轨，我强烈建议每个人尽可能在单个分支（或主干）上一起工作。我一直告诉开发人员在进行更改时要小规模。
您听起来需要的是一种自动化部署的方法。也就是说，我在本地计算机上进行更改，并使用单个命令，确保服务器具有代码的副本。您还希望部署高效。如果您更改 2 GB、10,000 个文件部署中的单个 2 KB 文件，您只想复制该文件，而不是 10,000 GB。为此，我建议您在 Ant 中编写部署脚本。
您的开发人员可以修改文件，然后通过 Ant 脚本部署这些文件。开发人员不必记住他们更新了哪些文件，因为 Ant 会自动处理这些问题。事实上，Ant 甚至可以修改文件以确保它们在复制时包含正确的环境信息。当然，如果服务器上的设置与源存储库中的设置不同，Ant 可以重新排列文件。 Netbeans 和 Eclipse 都可以直接在 IDE 中执行 Ant 脚本。
因此：
有人提到了像 Jenkins 这样的持续构建系统。无论如何，这实际上是一个好主意，即使它不能解决这个特定问题。 Jenkins 可以拥有自己的服务器和数据库。然后，当您提交代码时，Jenkins 将更新服务器并运行自动化测试。然后 Jenkins 可以创建报告。这一切都显示在 Jenkin 的网页上。另外，您可以在 Jenkins 上存档您的部署，因此，如果您告诉某人测试“Build #20”，他们可以简单地从 Jenkins 中轻松找到它。
I don't like working with personal branches. I worked with ClearCase for almost 15 years and even though ClearCase probably handles personal branching better than most, it was still a big pain. Even worse, personal branches encourages people to not commit their work until the last minute -- usually a day or two before a major release.
For that reason, and to force developers to stay on track with each other, I highly recommend everyone working together on a single branch (or on the trunk) as much as possible. I keep telling developers to take small bites when they make changes.
What you sound like you need is a way to automate the deployment. That is, I make changes on my local machine, and with a single command, I make sure that the server has a duplicate copy of the code. You also want the deployment to be efficient. If you change a single 2 kilobyte file of a 2 gigabyte, 10,000 file deployment, you only want to copy over that one file, not 10,000 gigabytes. For that, I would recommend you write a deployment script in Ant.
Your developers can modify files, then deploy those files via an Ant script. The developers don't have to remember what files they had updated because Ant will automatically handle that. In fact, Ant can even modify files to make sure they contain the right environment information as they get copied over. And, of course, Ant can rearrange the files if the setup on the server is different from the setup in the source repository. And both Netbeans and Eclipse can execute Ant scripts right in the IDE.
So:
Someone mentioned a Continuous Build System like Jenkins. That actually would be a good idea anyway even though it doesn't solve this particular issue. Jenkins could have its own server and database. Then when you commit your code, Jenkins would update the server and run automated tests. Jenkins can then create a report. It all gets displayed on Jenkin's webpage. Plus, you can archive your deployments on Jenkins, so if you tell someone to test "Build #20", they can simply pull it off of Jenkins where its easy to find.
我确信每个人都有不同的做事方式，但这是我的想法。
“最佳实践”可能是“持续集成”，即每个开发人员没有自己的分支，而是签入公共开发分支。这迫使他们尽早处理冲突并相互协调，以避免首席开发人员在以后管理巨大的火车残骸合并。如果你真的想走那条路，请看看巡航控制。
最好的方法是他们拥有本地 apache Web 服务器和完整的 php 堆栈。您可以使用 Zend_Server 社区版在 Windows 上快速启动和运行。大多数标准 php 代码在 Windows 和 Linux 上都可以正常运行，但如果您正在进行大量文件操作或 cron 作业或 cli 内容，或者需要 memecache 等，您将遇到不兼容的情况。如果是这种情况，并且只有 Linux 的东西会困扰您，那么您可以使用 VMWARE 或 VirtualBox 来运行本地 Linux 实例，并在其中安装 IDE，并确保它们有足够的 RAM 来处理它。
每个开发人员都需要在 Eclipse 内部运行同步，基本上是 svn 更新，当场处理与其他开发人员的任何冲突，进行本地测试并提交他们的更改。
我在 svn 服务器上设置了一个 post_commit 挂钩，它会调用我的 Web 服务器上的 /autobuild.php 。 autobuild.php 运行 svn update 并获取最新的代码更改以及任何 chown 或 chmod 文件权限内容并重置任何服务器特定的配置文件 config.php。设置它以便 apache 用户可以运行 svn update 有点棘手，但是一旦你完成了，你的 beta/测试服务器总是有最新提交的代码。 CruseControl 和其他几个工具也可以帮助您做这类事情并添加单元测试等
现在您的首席开发人员仍然有一项工作要做，将开发分支合并到生产分支中，在开发服务器上进行测试，并审查提交其他人并决定如何以及何时发布版本，但你不会把解决每个冲突和合并每个更改的负担交给他。
您的开发人员不会将文件或 ssh 远程传输到服务器，他们只是在 IDE 中本地工作并通过 svn（以及电子邮件、电话、聊天等）相互交互更新以获取新代码并在完成工作后提交。
我认为为每个使用 SVN 的开发人员建立一个单独的分支并没有什么好处。合并这些分支可能在 Git 中可行，但使用 SVN，您的首席开发人员很快就会讨厌这种类型的设置。
I'm sure everyone has different ways of doing things but here are my thoughts.
"Best Practice" is probably "Continous Integration" ie each developer doesn't have their own branch but checks in to a common development branch. This forces them to handle conflicts and coordinate with each other early and often to avoid the lead developer from managing a huge train wreck merge later down the road. Take a look at cruisecontrol if you really want to go that route.
The best way is if they have a local apache web server and full php stack. You can use the Zend_Server community edition to get up and running on windows fast. Most standard php code will run just fine on both Windows and Linux, but if you are doing lots of file manipulation or cron job or cli stuff, or need memecache, etc you'll run into incompatabilities. If thats the case and the Linux only stuff is going to bite you use VMWARE or VirtualBox to run local linux instances and install the IDE inside those and just make sure they have goobs of RAM to deal with it.
Each developer needs to run a syncronize inside of Eclipse, basically an svn update, deal with any conflicts with the other developers right then and there, do local testing and commit their changes.
I setup a post_commit hook on the svn server that calls and /autobuild.php on my web server. autobuild.php runs svn update and gets the latest code changes as well as does any chown or chmod file permissions stuff and resets any server specific config files config.php. Its a little tricky to get it setup so that the apache user can run svn update, but once you do your beta/testing server always has the latest committed code. CruseControl, and several others can also help you do this sort of thing and add unit testing, etc
Now your Lead Developer still has a job to do merging the Development Branch into the Production One, testing on the dev server, and reviewing the commits of the others and deciding how and when to push out a release, but your not putting the burden on him of resolving every conflict and merging every change.
Your developers are not ftping files or ssh remoting into servers, they just work locally in their IDE and interact with each other through svn (and email, phone, chat, etc) updating to get the new code and commiting as they finish things.
I don't see any good coming out of having a seperate branch for each developer using SVN. Merging those branches might work in Git but with SVN your lead developer will be hating life very quickly with that type of setup.