我一直在这里和那里阅读这个网站,好像你们有一个很棒的社区。 p>
至于我的背景,我是一名熟悉SQL,C ++,Visual Basic和一些PHP的大学二年级学生。我暑期学期的一个项目涉及构建一个Web应用程序,允许用户通过Internet登录和安排特定的时间段。通常情况下,我是唯一一个从事项目工作的人,但在这种情况下,我将成为一个团队的一员。由于我们作为一个团队工作相对较新,我想为我的团队设置源代码控制,所以我们不是所有人都在共享驱动器上工作。此外,我想确保我们所有人都能够在托管我们网站实例的某种开发服务器上测试我们的更改。
我的实际问题是关于我们应该用来实现这个目标的工具集。作为一个群体,我们最熟悉PHP和MySQL,因此我们最终会将其用于代码和数据库。我过去使用过SVN供我个人使用,但我的小组成员对源代码控制不是很熟悉。我们可能会在项目管理和错误跟踪方面坚持像Excel一样简单的东西。理想情况下,我们希望这些工具是免费和开源的。
我们应该如何管理实际应用程序的构建?有没有我可以使用的方法,允许我们任何一个人将文件移动到我们的开发机器并跟踪谁做了它,所以我们最终不会覆盖彼此的变化?如果这是不可能的,我们中的一个人会编写一些脚本来处理它 - 但我想避免构建一个基本上只用于管理我们项目的软件应用程序。我预见的另一个问题是更新在开发机器上运行的数据库。我们可以使用任何标准化方法来管理我们四个人之间的SQL脚本吗?
我不希望这里有一个非常冗长的答案(毕竟,这是我们的项目!),但任何有用的提示将不胜感激。一旦我从假期回来,我期待着开始!谢谢!
答案 0 :(得分:3)
我建议您的群组使用源代码控制来同步您的代码。您可以设置自己的服务器,也可以只使用免费提供商,例如github,Google code或bitbucket。
如果您决定使用其中一个网站,一个不错的功能是它们也提供免费的问题跟踪,因此您可以使用它而不是Excel。
管理SQL脚本的最佳方法是将它们分解为单独的文件,并将它们置于源代码控制之下。您可以创建.sql
个文件,也可以使用工具来管理这些更改 - 例如,查看Ruby on Rails' Migrations。这可能需要一些设置,但是如果您正在处理任何规模的项目,您将在以后感谢自己......
答案 1 :(得分:2)
答案 2 :(得分:2)
就源/版本控制而言,我建议使用subversion。他们可能会使用一些GUI工具,甚至webDAV来访问SVN。这将允许用户协同编辑文件,并为您提供有关谁编辑了什么,何时以及为什么的详细信息...... SVN还可以很好地合并恰好同时保存的文件。
这不是最容易理解的概念,但是一旦你开始运行它并不是很复杂。
我建议大家阅读第一章:http://svnbook.red-bean.com/en/1.5/
他们应该很清楚发生了什么。
我也很想知道人们对数据库的看法
答案 3 :(得分:0)
我们应该如何管理实际应用程序的构建?有没有我可以使用的方法,允许我们任何一个人将文件移动到我们的开发机器并跟踪谁做了它,所以我们最终不会覆盖彼此的变化?
听起来你正在寻找build management。在PHP的情况下,真正的“构建”就像源文件的集合一样简单,因为语言被解释;没有汇编。
恰好我是BuildMaster的开发人员之一,这个工具基本上解决了你在问题中列出的所有问题...而且听起来它在你的情况下也是免费的社区版许可证。我将尝试解决您的一些个人痛点以及如何将BuildMaster用作解决方案。
正如其他人所建议的那样,你必须使用它。部署时的诀窍是设置某种形式的continuous integration,以便每次有人签入时,都会创建一个新的“构建”。在BuildMaster中,您可以为任何所需的源控件提供程序进行设置。
Excel可以使用,但它不是最佳解决方案。您可以使用大量免费问题跟踪工具来管理您的错误和功能。使用BuildMaster,您可以通过其版本号将您的错误和功能列表与应用程序链接,以便您可以随时在工具中查看它们。它还可以根据需要自动修改问题状态和添加说明。
使用BuildMaster,您可以为您的开发环境创建自动部署计划,例如:
最好的部分是,一旦你为其他环境(glowcoder的第6点)设置了它们,推送所有代码和数据库更新就像点击按钮一样简单。
我预见的另一个问题是更新在开发机器上运行的数据库。我们可以使用任何标准化方法来管理我们四个人之间的SQL脚本吗?
毫不奇怪,BuildMaster通过使用更改脚本模块来处理这些问题。当您的团队成员创建脚本(例如ALTER TABLE ADD [Blah] INT NOT NULL
)时,他可以将其上传到BuildMaster,然后在您创建的任何环境中运行它。
最好的部分是您可以在自动部署中添加一个步骤,而不必再担心它。正如Justin所提到的,您可以将.sql
文件用于您的目标代码(存储过程,视图,触发器等),并在每次构建时执行这些文件,因为它们本质上都是代码。您可以将它们保留在源代码管理中。
你可能忽略了(但不可避免地会遇到)所有这一切的一个方面是处理配置文件。使用PHP,您可能拥有.htaccess文件,php.ini文件,prepend.php或滚动您自己的自定义配置文件。因为根据定义,配置文件需要在您的个人计算机和开发计算机之间进行更改,所以如果没有一点点黑客攻击,从源代码控制中获取它们就没有必要了。
if (DEV) {
// do one thing
}
else if (PROD) {
// do another
}
使用BuildMaster,您可以模拟配置文件并将其与环境相关联,以便可以自动部署它们。它还将为您保留变化的历史。
如果您想要完整的ALM效果,您可以在自动构建期间自动对代码进行单元测试,并在出现任何故障时通知您,以便您尽快知道某些内容已损坏。
为“长篇大论”的回应道歉,但我觉得你已经通过观察未来可能遇到的问题已经领先于游戏,并且真的相信BuildMaster会让你的团队简化所有这些部署工作所以你可以专注于有趣的部分,编码!