问题标签 [sdlc]

我们公司正在尝试强制执行测试驱动开发，作为开发经理，我正在尝试定义验收标准的真正含义。我们主要遵循敏捷方法，每个要测试的故事都需要一定程度的单元测试覆盖率保证（入口标准）。我很想听听你们如何在公司内部有效地从门控级别执行此操作（如果您这样做的话）。

我正在使用 Visual Studio 2013 Preview，尽管我确信我在早期版本中看到过它。使用向导创建新项目时，我选择 C++、Win32 控制台应用程序，并且有一个选项可以在我的项目上启用安全开发生命周期检查。有人可以准确解释这个选项对我的代码/项目有什么作用吗？

我们正在考虑将Flyway集成到我们的应用程序中，但担心它维护自己的版本的方式以及它如何与软件开发生命周期 (SDLC)一起工作。

本质上，我们使用该方法的问题是您维护一组按文件名中的版本分隔的 SQL 脚本，而不是在版本控制中维护一个主干并将该主干发布/标记为特定版本。使用 Flyway，开发人员可以返回并更改与您的应用程序的已发布版本相关的旧迁移脚本，并破坏您已经集成/测试/暂存并交付到生产环境的版本。

我们正在考虑做的是在版本控制下维护项目中的 SQL 迁移（即 my-app-db/trunk/migration.sql），并在 SQL 开发人员声明它已准备好发布时从那里发布/标记（V1 .0.0__blah.sql)。然后清除trunk/migration.sql，以便可以开发和标记下一个1.0.1 或1.1.0 脚本。然后，包装脚本将从标签中导出 SQL 文件，使用该目录调用 Flyway 以执行迁移，并清理导出。

这看起来像是一个有效的观点/方法吗？Flyway 会支持版本控制之类的东西吗？

我完成了一个功能请求，需要更改我们网站的数据库。

将数据库更改传播到软件开发生命周期的测试和生产阶段的标准方法是什么？我工作的人建议我们没有为此制定程序，但我们应该这样做。

在版本控制的上下文中执行此操作的常用方法是什么？

我正在考虑在自述文件中包含对测试人员/部署人员的说明，以在尝试启动站点之前通过 psql 执行项目中包含的 SQL 脚本。但我不希望该脚本保留在后代分支中，对吗？还是我？对数据库的所有更改都应该以某种方式集中的答案吗？

这里的部分问题可能是我不知道更精确的方式来问这个问题，所以很难谷歌。非常欢迎任何建议，谢谢！

我看到有一个包含 2013 年 SDL（安全开发生命周期）的 TFS 模板（http://www.microsoft.com/en-us/download/details.aspx?id=42517），但它没有提及 TFS2012 的任何内容。

有谁知道它是否与 TFS2012 兼容，或者是否有 2012 的 SDL 模板？（我不想安装2013版本，只是为了它破坏我们的TFS2012！）

我正在使用 Microsoft 的 BinScope 来测试任意可执行文件。BinScope 是一个 SDLC 合规工具。

该工具为GSFunctionOptimizeCheck和GSFunctionSafeBuffersCheck（以及其他）标记了一个可执行文件。我对他们中的任何一个都不熟悉。

搜索在网络上返回了大约 10 个结果，在 Stack Overflow 上返回了 0 个结果。微软的 BinScope 帮助页面没有提到它。

什么是GSFunctionOptimizeCheck和GSFunctionSafeBuffersCheck，补救措施是什么？

我已经阅读了软件开发生命周期和需要开发的初始项目的不同方法。任何人都可以建议和解释对现有项目进行软件升级或更新的不同方法吗？

我继承了一个大型代码库，其中开发分支在 git 下已经有一段时间了，但生产并没有受到任何版本控制。

..我知道。

将代码提升到生产环境的方法是从 dev 和 prod 手动来回复制所有更改的文件，直到它们同步，并在周末尽快处理随后的灾难。

从那以后，我将生产置于一个全新的 git 实例下git init/add/commit，现在可以跟踪所有这些在生产中实时生成的修补程序（当我回到每个人后面并每天进行检查点提交时）。我已将生产上的“起源”设置为与开发相同，因此生产现在是同一存储库的单独分支，没有共同的祖先。

我想在这里进行真正的开发过程，这意味着我想将分支合并在一起。

在这一点上值得一提的是，开发和生产分支都在进行，因为首席开发人员喜欢在生产中进行热修复。我相信我可以改变他的这种习惯，如果我可以提供将修复应用到另一个分支并将其合并到生产中的替代方案。

但要做到这一点，我需要一个与生产共享共同祖先的分支。

..我该怎么办？我可以将生产合并到开发中，这会产生大量冲突，我可以尝试手动解决（即合并工具），但这听起来像是大量的工作。

有没有更好的办法？

我仍在学习成为一名 git 大师，我想完成这件事，但是.. 最好的方法是什么？

当许多开发人员都在做同样的事情（不能进一步拆分）并且您仍然希望每天进行部署时，我有几个关于如何处理测试和部署的问题。

目前我们关注 Gitflow，我们有我们的功能分支，每个人都在开发一个孤立的功能。功能被合并到开发分支中。我们不时地花一些时间来满足用户需求/错误修复/快速功能等。

最终目标是让那些尽快生产。我的问题是你会建议什么样的过程：

1）我们可以在不引入官僚主义的情况下进行部署（例如每个月的最后一个星期五发布）。

2) 如果某人提交了引入错误的代码，它不会影响其他提交了无错误代码的人。换句话说，如果 Coder A 试图通过引入一个新的 bug 来修复 bug，而 coder B 已经修复了他的 bug，那么 coder B 的代码将进一步进入管道，而 coder A 将迟到修复 bug :)

3）我们不能拥有无限的测试环境。我们也不想花一天时间设置测试环境。我们需要一个可以解决此要求的解决方案（因此，除非我遗漏了什么，否则不能选择对功能分支进行测试）

3) 测试人员毫无疑问地确切地知道他们批准什么进入生产。

顺便说一句，我们有一套相当广泛的单元/功能测试，但这个问题是关于过程的，所以这些并不是真正相关的。

此外，我已经研究了所有其他问题，但没有什么能真正解决我所有的问题。如果你认为有一个，我会很乐意看看。

谢谢

应用程序生命周期管理和软件开发生命周期有什么区别？