小型团队的开发工作流程 [英] Development workflow for small team

问题描述

因此，我在一家小型活动/娱乐公司工作，最近接手了开发团队(大多数时间，PHP应用程序)的职责.当前的工作流程看起来像这样:

So, I'm working in a small event/entertainment company and have recently taken over responsibility for the development team (PHP applications, most of the time). The current workflow looks kind of like this:

• 每个项目都有一个开发和生产服务器.没有本地开发环境，这意味着每个开发人员都具有SSH访问权限，并且可以直接在开发服务器上进行更改.
• 没有任何源代码控制.
• 大多数时候，团队中的每个成员都自己完成一个项目.很少有多个开发人员在同一个项目上工作.
• 更新生产服务器意味着使用SFTP将源从开发人员转移到生产服务器.

我觉得这很可怕，所以我想到了这个主意:

I find this rather horrible, so I came up with this idea:

• 将有一个中央开发服务器托管所有可用的项目，该服务器将使用Mercurial进行源代码控制.
• 开发人员必须设置本地开发环境，并为每个项目使用本地存储库.更改可以从开发服务器上的中央存储库中拉出/推入.
• 如果必须推出新版本的项目，开发人员可以将存储库克隆到生产服务器.

这种工作流程有什么问题吗?我曾经在自己的项目中使用过Mercurial，但以前从未在团队中使用过Mercurial，而且我对所有这些团队管理人员都是陌生的.我希望您能提出一些建议.

Is there anything completely wrong with this kind of workflow? I've used Mercurial for my own projects, but I've never used it in a team before and I'm new to all this team-managing-stuff too. I'd appreciate some suggestions.

谢谢， 克里斯

推荐答案

让您的开发人员在本地工作很有意义. PHP的最大优点是反馈周期短，如果他们必须将可能损坏的内容推送到共享的开发盒中，那么这将缩短反馈周期.您可能可以使用Vagrant之类的工具来简化开发人员在其开发计算机上的环境设置.

It makes a lot of sense to have your developers work locally. The biggest advantage of PHP is the short feedback cycle, and if they have to push potentially broken stuff onto a shared development box, then that breaks the short feedback cycle. You may be able to use something like Vagrant to make environment setup easier for the developers on their development machines.

就其余部分而言:我将把您的开发/测试服务器从中央存储库中分离出来.原因是在您处理项目时，您可能会开始将分支用于不同的发行版本.您的项目可能会有一个稳定"/当前发布的分支，一个功能"分支(正在处理的新内容).对于我建议的基本分支工作流，直接释放给开发服务器实际上并没有任何意义.

As far as the rest of it: I would split your development/test server off from your central repository. The reason being as you work on your project it's likely that you guys will begin to use branches for different release versions. It's likely that there will be a "Stable"/Currently released branch of your project and a "Feature" branch (New stuff you're working on). Releasing directly to the development server doesn't really make sense for even a basic branched workflow like I'm suggesting.

我在这里看到的另一个大问题是，所有开发人员都可以向生产服务器发布版本.通常，即使在较小的组织中，在发布到生产服务器之前，也会有指定的人员和指定的条件.我建议您这样做.同样，在发布之前，你们应该始终标记要发布的版本.那应该是您的发布工作流程的一部分.

The other big issue I see here is all of your developers can do releases to the production server. Typically, even in smaller organizations there's a designated person and designated criteria prior to releasing to the production server. I would recommend you do this. Also prior to releasing you guys should ALWAYS tag the version you're releasing. That should be part of your release workflow.

您没有提到的另一件事是问题跟踪.就我而言，JIRA是问题跟踪软件的黄金标准.我们喜欢使用JIRA和Fisheye来管理我们的代码并协调特定问题的提交.

The other thing you're not mentioning is issue tracking. As far as I'm concerned JIRA is the gold standard for issue tracking software. We like to use JIRA and Fisheye to manage our code and coordinate commits with specific issues.

这篇关于小型团队的开发工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！