我正在使用 Visual Studio、TFS 2015、Visual Studio Team Services 和 Azure/本地或远程 IIS 来实现持续集成。 我正在从下面的 stackoverflow 阅读 Continuous Integration vs. Continuous Delivery vs. Continuous Deployment
- 我/我的团队将代码 checkin TFS 存储库,并在我每次 checkin 代码时配置自动构建;是持续集成吗?
- 我已经配置了构建。它运行 nuget 包管理器,运行测试,执行构建并将构建的程序集放到指定位置。是持续交付吗?
- 我已经配置部署到 Azure/IIS。我还启用了持续集成。因此,每当我/我的团队 checkin 代码时,它都会运行构建并部署到生产/状态服务器。是持续部署吗?
- 当我一次单击即可执行上述所有操作时,这称为 DevOps 吗?
- 使用 Selenium/MS Build 进行手动测试的作用在哪里?
请添加输入,如果我哪里出错了请告诉我。
最佳答案
- 是的。准确的说,它只是CI的一种形式。在 TFS 中,这是 称为 CI 构建。您可以通过选择 CI 触发器来实现此目的 构建定义。
- 是的。这也是持续交付的一种实现方式。
- 是的。持续部署被描述为合乎逻辑的下一步 持续交付后:自动将产品部署到 只要通过质量检查就可以生产。
否。持续交付和DevOps在含义上相似并且是 经常混为一谈,但它们是两个不同的概念。DevOps 有一个 范围更广,并以文化变革为中心,特别是 参与软件交付的各个团队的协作 (开发人员、运营、质量保证、管理等),作为 以及自动化软件交付过程。连续的 另一方面,交付是一种自动化交付的方法 方面,并侧重于汇集不同的过程和 更快更频繁地执行它们。他们有共同点 最终目标,并经常结合使用以实现这些目标。开发运维 和持续交付共享敏捷方法和精益的背景 思考:小而快的变化,将值(value)集中到最后 顾客。他们在内部沟通和协作良好, 从而帮助缩短上市时间并降低风险。
手动测试是一个耗时且劳动密集型的过程 确保一个软件不管怎样都能做它应该做的事 它开发得很快。团队有时过于依赖单元测试而忽视自动化和验收测试。 CI也有一些风险和挑战。这只是其中之一。
关于continuous-integration - 从应用程序的角度来看持续集成、持续交付、持续部署,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38419254/