作为团队的一部分，我如何管理我的网站的开发和部署?

I've been reading this site here and there and appears as though you guys have a wonderful community.

我一直在到处看这个网站，好像你们有一个很棒的社区。

As for my background, I am a sophomore at university familiar with SQL, C++, Visual Basic, and some PHP. One of my school projects for the summer term involves building a web application that allows users to log in and schedule specific timeslots over the internet. Typically, I have been the only person working on a project, but in this case I will be part of a group. Since we're all relatively new to working as a team, I would like to set up source control for my group so we're not all working off a shared drive somewhere. Additionally, I would like to make sure that all of us are able to test our changes in some sort of development server that hosts an instance of our website.

关于我的背景，我是一名大二的学生，熟悉SQL, c++， Visual Basic，和一些PHP。我的一个暑期学校项目涉及到构建一个web应用程序，它允许用户登录并在互联网上安排特定的时间段。通常情况下，我是唯一参与项目的人，但在这种情况下，我将成为团队的一部分。由于我们都是一个相对较新的团队，所以我想为我的团队建立源码控制，这样我们就不会在某个地方工作了。此外，我希望确保我们所有人都能够在托管我们网站实例的某种开发服务器中测试我们的更改。

My actual question is in regards to the toolset that we should use to achieve this. As a group, we are most familiar with PHP and MySQL so we'll end up using that for the code and database. I have used SVN in the past for my own personal use, but my group members aren't very familiar with source control. We'll probably stick with something simple like Excel for the project management and bug tracking side of things. Ideally, we would like the tools to be free and open source.

我真正的问题是关于我们应该用来实现这一点的工具集。作为一个团队，我们最熟悉PHP和MySQL，所以我们最后会在代码和数据库中使用它。我过去曾使用过SVN作为个人使用，但我的小组成员对源代码控制不太熟悉。我们可能会在项目管理和bug跟踪方面坚持使用Excel之类的简单工具。理想情况下，我们希望工具是免费的和开源的。

How as a group should we manage the construction of the actual application? Are there methods out there that I can use that will allow any one of us to move the files to our development machine and keep track of who did it so we don't end up overwriting each other's changes? If this is not possible, one of us will write some scripts to handle it - but I would like to avoid building basically a separate software application that will only be used to manage our project. Another issue I foresee will be updating the database running on the development machine. Are there any standardised methods that we can use to manage our SQL scripts among the four of us?

作为一个团队，我们应该如何管理实际应用的构建?是否有我可以使用的方法可以让我们中的任何人将文件移动到我们的开发机器并跟踪是谁做的，这样我们就不会覆盖彼此的更改?如果这是不可能的，我们中的一个将编写一些脚本来处理它——但是我希望避免构建一个基本上只用于管理项目的单独的软件应用程序。我预见的另一个问题是更新在开发机器上运行的数据库。在我们四个人当中，有什么标准化的方法可以用来管理SQL脚本吗?

I do not expect a really long winded answer here (after all, this is our project!), but any helpful tips would be greatly appreciated. Once I return from holiday I am looking forward to getting started! Thanks!

我不期望在这里有一个冗长的答案(毕竟，这是我们的项目!)，但是任何有用的提示都会非常感谢。一旦我从假期回来，我期待着开始!谢谢!

4 个解决方案

#1

I recommend your group use source control to synchronize your code. You can either setup your own server or just use a free provider such as github, Google code, or bitbucket.

我建议您的组使用源代码控制来同步您的代码。您可以设置自己的服务器，也可以使用免费的提供者，如github、谷歌代码或bitbucket。

If you do decide to use one of these sites, a nice feature is that they provide free issue tracking as well, so you can use that instead of Excel.

如果您决定使用这些站点之一，一个好的特性是它们提供免费的问题跟踪，所以您可以使用它而不是Excel。

The best way to manage the SQL scripts is to break them out into separate files and place them under source control as well. You can either create .sql files, or use a tool to manage these changes - for example, have a look at Ruby on Rails' Migrations. This may take some effort to setup, but you'll thank yourself later if you are working on a project of any size...

管理SQL脚本的最佳方法是将它们分解为不同的文件，并将它们置于源代码控制之下。您可以创建.sql文件，或者使用工具来管理这些更改——例如，查看Ruby on Rails的迁移。这可能需要一些努力来设置，但是如果您正在进行任何规模的项目，您将在稍后感谢您自己……

#2

1. Draw up a plan for how you would do it if it were just you.
2. 制定一个计划，如果只有你，你会怎么做。
3. Split the plan up into tasks that take around 3-4 hours to complete. Make sure each task has a measurable objective.
4. 把计划分成3-4个小时完成的任务。确保每个任务都有一个可衡量的目标。
5. Divy out the tasks. Try to sort them if possible to maximize developer efficiency.
6. Divy任务。尽可能地对它们进行排序，以最大化开发人员的效率。
7. Teach them to use source control. Explain to them that they will use this (maybe not svn, but SOMETHING) in a few years, so they might as well learn how now. Additionally, this will help in every group project they do down the road.
8. 教他们使用源代码控制。向他们解释，他们将在几年内使用这个(也许不是svn，而是一些东西)，所以他们也可以学习现在。此外，这也将有助于他们今后的团队项目。
9. Make a script for building and running your tests. Also script your deployment. This will ensure you have the same mechanism going to live as you do going to test, which increases the number of defects found in testing. (This is as opposed to letting them exist but not found in testing.)
10. 为构建和运行测试编写一个脚本。您的部署脚本。这将确保您拥有与将要进行测试相同的机制，这将增加在测试中发现的缺陷的数量。(这与让它们存在而不是在测试中发现是相反的。)
11. You mentioned updating the development database. It would be entirely reasonable to dump the development database often with a refresh from live. You may want to make 3 environments. Development, staging, and production. The development database would contain fabricated test data. The staging database would have a copy of live (recent to within a few days maybe.) And of course live is live.
12. 您提到了更新开发数据库。通常在动态刷新时转储开发数据库是完全合理的。您可能想要创建三个环境。开发、分期和生产。开发数据库将包含伪造的测试数据。登台数据库将有一个实时的副本(最近到几天内可能)。当然，生活就是生活。
13. Excel works fine as a "bug database." Consider putting it in source control that you manipulate and commit. This will give you a good idea of what happened over time, and you can correct mistakes quicker.
14. Excel作为一个“bug数据库”很好用。考虑将它放在您操作和提交的源代码控制中。这将使您对随着时间的推移发生的事情有一个很好的了解，并且您可以更快地纠正错误。

#3

As far as source/version control, I would recommend subversion. There are some GUI tools they might use, or even webDAV to access the SVN. This will allow users to edit files collaboratively and also give you details as to who edited what, when, and why... SVN will also do a pretty good job at merging files that happen to be saved at the same time.

至于源代码/版本控制，我推荐subversion。他们可能会使用一些GUI工具，甚至webDAV来访问SVN。这将允许用户协同编辑文件，并提供关于谁编辑了什么、何时、为什么……SVN还将在合并同时保存的文件方面做得很好。

It's not the easiest concept to wrap your head around, but its not very complicated once you get running.

这并不是最简单的概念，但一旦你开始跑步，它就不是很复杂了。

I suggest having everyone read the first chapter from: http://svnbook.red-bean.com/en/1.5/

我建议大家读一下第一章:http://svnbook.red-bean.com/en/1.5/

and they should have a good idea of what's happening.

他们应该对发生的事情有一个很好的了解。

I am also curious to see what people have to say about the database

我也很想知道人们对这个数据库有什么看法

#4

How as a group should we manage the construction of the actual application? Are there methods out there that I can use that will allow any one of us to move the files to our development machine and keep track of who did it so we don't end up overwriting each other's changes?

作为一个团队，我们应该如何管理实际应用的构建?是否有我可以使用的方法可以让我们中的任何人将文件移动到我们的开发机器并跟踪是谁做的，这样我们就不会覆盖彼此的更改?

It sounds like you're looking for build management. In the case of PHP, a true "build" is as simple as a collection of source files because the language is interpreted; there is no compilation.

听起来您在寻找构建管理。在PHP中，真正的“构建”就像源文件的集合一样简单，因为语言是被解释的;没有编译。

It just so happens that I am one of the developers for BuildMaster, a tool which basically solves every problem you have listed in your question... and it also sounds like it would be free in your case under the Community Edition license. I'll try to address some of your individual pain points and how BuildMaster could be used as a solution.

碰巧的是，我是BuildMaster的开发人员之一，这个工具基本上可以解决问题中列出的所有问题……而且它听起来像在社区版许可证下的免费。我将尝试解决您的一些个人痛点，以及如何使用BuildMaster作为解决方案。

Source Control

As suggested by others, you must use it. The trick when it comes to deployment is to set up some form of continuous integration so that every time someone checks in, a new "build" is created. In BuildMaster, you can set this up for any source control provider you want.

正如其他人建议的，你必须使用它。在部署方面的技巧是建立某种形式的持续集成，以便每次有人登录时，都会创建一个新的“构建”。在BuildMaster中，您可以为您想要的任何源代码控制提供程序设置此选项。

Issue/Bug Tracking

Excel will work, but it's not an optimal solution. There are plenty of free issue tracking tools you can use to manage your bugs and features. With BuildMaster, you can link your bugs and features list with the application by their release number so you could view them within the tool at any time. It can also modify issue statuses and add descriptions automatically if you want.

Excel会有用，但不是最佳的解决方案。有很多免费的问题跟踪工具可以用来管理您的bug和特性。使用BuildMaster，您可以将您的bug和特性列表与应用程序链接到它们的发布编号，以便您可以随时在工具中查看它们。它还可以修改问题状态并自动添加描述。

Deployments

Using BuildMaster, you can create automated deployment plans for your development environment, e.g.:

使用BuildMaster，您可以为您的开发环境创建自动部署计划，例如:

1. Get Latest Source Code
2. 得到最新的源代码
3. Create Artifact
4. 创建工件
5. Copy Files To Development Machine
6. 将文件复制到开发机器
7. Deploy Configuration Files
8. 部署配置文件
9. Update Database
10. 更新数据库

The best part is, once you set these up for other environments (glowcoder's point #6), pushing all of your code and database updates is as simple as clicking a button.

最好的部分是，一旦您将这些设置为其他环境(glowcoder的第6点)，那么推动所有代码和数据库更新就像点击一个按钮一样简单。

Another issue I foresee will be updating the database running on the development machine. Are there any standardised methods that we can use to manage our SQL scripts among the four of us?

我预见的另一个问题是更新在开发机器上运行的数据库。在我们四个人当中，有什么标准化的方法可以用来管理SQL脚本吗?

Database Updates

Not surprisingly, BuildMaster handles these as well by using the change scripts module. When a member of your team creates a script (e.g. ALTER TABLE ADD [Blah] INT NOT NULL) he can upload it into BuildMaster, then run it on any environment you have created.

毫不奇怪，BuildMaster也通过使用change scripts模块来处理这些问题。当您的团队成员创建一个脚本(例如，ALTER TABLE ADD [Blah] INT NOT NULL)时，他可以将它上传到BuildMaster，然后在您创建的任何环境中运行它。

The best part is that you can add a step in your automated deployment and never worry about it again. As Justin mentions, you can use .sql files for your object code (stored procedures, views, triggers, etc.) and have those executed on every build since they are essentially code anyway. You can keep those in source control.

最棒的是，您可以在您的自动部署中添加一个步骤，而不必再担心它。正如Justin提到的，您可以使用.sql文件为您的对象代码(存储过程、视图、触发器等)，并在每个构建中执行这些文件，因为它们本质上是代码。您可以将它们保存在源代码控制中。

Configuration Files

One aspect of all this you may have neglected (but will inevitably run into) is dealing with configuration files. With PHP, you may have an .htaccess file, a php.ini file, a prepend.php, or roll your own custom config file. Since by definition configuration files need to change between your personal machine and the development machine, grabbing them from source control wouldn't necessary work without some bit of hacking a la:

您可能忽略了(但不可避免地会遇到)所有这些的一个方面是处理配置文件。使用PHP，您可能有一个.htaccess文件，一个PHP。ini文件,预谋。php，或滚动您自己的自定义配置文件。因为根据定义，配置文件需要在您的个人机器和开发机器之间进行更改，从源代码控制中获取这些配置文件不需要进行一些黑客攻击:

if (DEV) {
    // do one thing
}
else if (PROD) {
    // do another
}

With BuildMaster, you can templatize your configuration files and associate them with an environment so they can be deployed automatically. It will also maintain a history of changes for you.

使用BuildMaster，您可以对您的配置文件进行模板化，并将它们与环境相关联，这样它们就可以自动部署。它还将为您维护更改的历史。

Automated Testing

If you want the full ALM effect, you can automatically unit test your code during an automated build, and notify you if anything fails so you know as soon as possible that something is broken.

如果您想要得到完整的ALM效果，您可以在自动构建期间自动地对代码进行单元测试，如果有任何东西失败了，则通知您，以便您尽快知道有什么东西坏了。

---

Apologies for the "long winded" response, but I feel like you're already ahead of the game by observing the problems you might run into in the future and really believe BuildMaster will make all of this deployment stuff simple for your team so you can focus on the fun part, coding!

道歉的“长篇大论”的反应,但我觉得你已经领先通过观察你将来可能遇到的问题,真的相信BuildMaster将使所有这一切部署的东西简单的为你的团队可以关注有趣的部分,编码!