continuous-integration - 从应用程序的角度来看持续集成、持续交付、持续部署

标签 continuous-integration tfs-2015 continuous-deployment devops continuous-delivery

我正在使用 Visual Studio、TFS 2015、Visual Studio Team Services 和 Azure/本地或远程 IIS 来实现持续集成。 我正在从下面的 stackoverflow 阅读 Continuous Integration vs. Continuous Delivery vs. Continuous Deployment

  1. 我/我的团队将代码 checkin TFS 存储库,并在我每次 checkin 代码时配置自动构建;是持续集成吗?
  2. 我已经配置了构建。它运行 nuget 包管理器,运行测试,执行构建并将构建的程序集放到指定位置。是持续交付吗?
  3. 我已经配置部署到 Azure/IIS。我还启用了持续集成。因此,每当我/我的团队 checkin 代码时,它都会运行构建并部署到生产/状态服务器。是持续部署吗?
  4. 当我一次单击即可执行上述所有操作时,这称为 DevOps 吗?
  5. 使用 Selenium/MS Build 进行手动测试的作用在哪里?

请添加输入,如果我哪里出错了请告诉我。

最佳答案

  1. 是的。准确的说,它只是CI的一种形式。在 TFS 中,这是 称为 CI 构建。您可以通过选择 CI 触发器来实现此目的 构建定义。
  2. 是的。这也是持续交付的一种实现方式。
  3. 是的。持续部署被描述为合乎逻辑的下一步 持续交付后:自动将产品部署到 只要通过质量检查就可以生产。
  4. 否。持续交付DevOps在含义上相似并且是 经常混为一谈,但它们是两个不同的概念。DevOps 有一个 范围更广,并以文化变革为中心,特别是 参与软件交付的各个团队的协作 (开发人员、运营、质量保证、管理等),作为 以及自动化软件交付过程。连续的 另一方面,交付是一种自动化交付的方法 方面,并侧重于汇集不同的过程和 更快更频繁地执行它们。他们有共同点 最终目标,并经常结合使用以实现这些目标。开发运维 和持续交付共享敏捷方法和精益的背景 思考:小而快的变化,将值(value)集中到最后 顾客。他们在内部沟通和协作良好, 从而帮助缩短上市时间并降低风险。

  5. 手动测试是一个耗时劳动密集型的过程 确保一个软件不管怎样都能做它应该做的事 它开发得很快。团队有时过于依赖单元测试而忽视自动化和验收测试。 CI也有一些风险和挑战。这只是其中之一。

关于continuous-integration - 从应用程序的角度来看持续集成、持续交付、持续部署,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38419254/

相关文章:

docker - 如何实现滚动更新和关系数据库?

bash - 在 Jenkins 中的构建步骤之间传递数据

ant - 如何从 TeamCity 中提取工件?

tfs-2015 - 拉取请求的 TFS 2015.1 警报未显示在多个源代码管理集合中

docker - .env文件通过DevOps CD管道部署时标记为不是对象

jenkins - 截至 2015 年初,持续集成与功能分支的最新技术水平如何?

google-apps-script - Google Apps 脚本和 Cloudbuild CI 登录

node.js - TeamCity、NodeJS 和 API 测试

tfs - 如何阻止团队创建新的基于 XAML 的构建定义

testing - 如何在 TFS 2015 中自定义代码覆盖率摘要