这三个术语有什么区别？我的大学提供以下定义:

持续集成基本上只意味着开发人员的工作副本每天都会与共享主线同步几次.

持续交付被描述为持续集成的逻辑演变:始终能够将产品投入生产!

持续部署被描述为持续交付后的逻辑下一步:每当通过QA时自动将产品部署到生产中!

它们还提供警告:如果您能够连续部署到测试系统,有时也会使用术语"持续部署".

所有这些让我感到困惑.任何更详细的解释(或附带一个例子)是值得赞赏的!

我使用以下方法远程调用Jenkins作业:

wget http://<ServerIP>:8080/job/Test-Jenkins/build?token=DOIT

这里Test-Jenkins调用了job,它DOIT是我使用过的安全令牌.

现在我需要将一些参数传递给此作业的build.xml文件,即Test-Jenkins.

我还没有弄清楚如何传递变量.

使用Jenkins 2 Pipeline插件,有一个有用的功能,可以快速浏览管道阶段和步骤状态,包括记录输出.

但是,如果您使用"Shell脚本"(sh)步骤,似乎没有办法用有用的名称标记该脚本,因此显示只显示一个长的"Shell脚本"列表(显示在图片如下).

如何指定有用的名称,或者如何使用其他步骤来实现相同的效果？

我有一个Web应用程序,我们可以在功能准备就绪时部署到生产环境,有时可能每天运行几次,有时可能需要几周时间才能发布.

目前,我们没有为我们的项目增加我们的版本号,而且所有版本都在版本中0.0.1-SNAPSHOT保存了一年多.我想知道为Web应用程序进行持续交付的Maven方式是什么.在每次提交时提高版本号并且从不像我们现在所做的那样碰撞版本号似乎有点过分,似乎也是错误的.

对于此类Maven使用,建议的最佳做法是什么？

问题实际上是双重问题:

• 在单个pom.xml文件中推进项目版本号(可以有很多).
• 更新所有相关组件中的版本号以使用彼此的最新版本号.

最近我在看Ansible,并希望在项目中使用它.还有另一个工具Rundeck可以用来做各种操作工作.我对这两种工具都没有经验,这是我目前对它们的理解:

类似的观点

• 这两个工具都是无代理的,并使用SSH在远程服务器上执行命令

• Rundeck的主要概念是Node,与Ansible的库存相同,关键思想是定义/管理/分组目标服务器

• Rundeck可以在选定的节点上执行ad-hoc命令,Ansible也可以非常方便地执行此操作.
• Rundeck可以定义工作流并在选定的节点上执行,这可以通过编写playbook来使用Ansible完成
• Rundeck可以与Jenkins等CI工具集成进行部署工作,我们也可以定义一个Jenkins作业来运行ansible-playbook来进行部署工作

不同点

• Rundeck有Job的概念,Ansible没有

• Rundeck有Job Scheduler,Ansible只能通过Jenkins或Cron任务等其他工具实现这一点

• 默认情况下,Rundeck免费提供Web UI,但您必须支付Ansible Tower的费用

似乎Ansible和Rundeck都可用于执行配置/管理/部署工作,可能以不同的方式.所以我的问题是:

• 这两种补充工具是否设计用于不同目的？如果它们是补充工具,为什么Ansibl只与Chef/Puppet/Slat等工具相比而不与Rundeck相比？如果他们不是为什么他们有这么多相似的功能？
• 我们已经在使用Jenkins for CI,构建一个Continuous-Delivery管道,哪个工具(Ansible/Rundeck)更适合用于部署？
• 如果它们可以一起使用,那么最佳做法是什么？

非常感谢任何建议和经验分享.

我们一直在进行持续集成和持续交付,因为Subversion会在管道触发时提交.最近,我们开始在git-flow的一些项目中使用git,我们正在尝试决定使用git-flow的哪个分支来触发持续集成和连续交付管道.

这有两种方法:

1.使用开发分支

问题:使用git-flow我们应该在生产中部署发布(或主)分支,因此我们必须构建两个不同的管道,一个用于持续集成(分支开发),一个用于连续交付(分支主服务器).这可能会在生产中引入错误,因为生产中的版本与其他环境中的版本(集成,测试,登台)不同.

2.使用主分支:

问题:这样,我们就不会有真正的持续集成,因为对这些分支的更改不会频繁推送.

哪个是在管道中使用的rigth分支？

关于持续交付中的版本控制,我有一些具体问题.我想我了解全球工作流程或多或少是这样的:

1) Code
2) Push to version Control
3) Continuous Integration (unit, integration and end-to-end auto testing)
4) Artifacts deployment

版本控制怎么样？如何管理构建版本？

假设我们正在开发一个基于Maven的语义版本项目:major.minor.build.

当开发人员提交对VCS的更改并且CI服务器执行构建时,CI服务器是否应增加构建版本并在VCS中创建标记？

这个构建版本是否存在于源代码中？如果是这样,在每次推送到VC​​S之后,开发人员应该更新项目,因为CI服务器在项目上提交了更改(版本增量).

我有点困惑,我想以实用的方式理解CD工作流程.

持续集成概念刚刚集成在我的团队中.

假设我们有一个名为Dev的集成分支.

从它派生出3个分支,每个特定的当前项目一个:

• 项目A.
• 项目B.
• 项目C.

首先,Teamcity在专用服务器上配置,其目标是:

从包括Dev在内的每个分支的版本化源编译并启动单元和集成测试

然后,当然,每个项目分支(A,B和C)必须在克隆的生产环境中进行测试,以便可以执行UAT.

但我想知道我们应该部署什么频率？每次源代码更改？

我们是否应该仅将包含3个项目的混合的Dev部署到它(与下一个生产版本中的实际情况相对应)或3个项目独立后进行部署？

如果部署了Dev,则不得考虑将来可能对Dev进行更改.实际上,可能会有一个名为Project D的新项目,并且不得成为下一个版本的一部分.因此,采用Dev进行集成(UAT)是有风险的,因为部署者可以非自愿地整合项目D的内容,因此环境不会揭示下一版本的实际情况.

其他解决方案:我们不是采用Dev而是独立采用3个项目,那么是否必须同时存在3个克隆生产环境？

如果是,UAT可能不可靠,因为集成环境的行为可能经常发生变化......

UAT持续部署的概念对我来说并不清楚......

我正在开发一个 iOS 应用程序并使用 App Distribution 将我的测试版本分发给 QA 团队，我之前没有遇到任何问题，一切都很顺利和漂亮（考虑到 iOS 开发，呵呵）......但最近我遇到了一个问题我无法解决，我没有找到任何关于它的文档。

我不断地向项目添加新的测试设备（随着 QA 团队的发展）并遵循相同的步骤......

• 将新帐户添加到 Firebase 中的测试人员列表中。

• 使用新设备的 UDID 获取注册尝试。

• 在 Apple Developer Console 中注册新设备 UDID

• 通过 App Distribution 分发新版本的应用程序。

• 在设备中安装证书

• 瞧，下载新的发行版。

但这次的情况就不一样了……因为在这款最新的iOS版本的iPhone XS Max中，下载按钮从来没有出现过，我们只能看到下面的消息：“等待开发者”。

我尝试了很多不同的解决方案，重新下载并导入配置文件，重新分发应用程序，创建新配置文件，在 Fastlane 中强制使用新设备，在开发人员控制台中删除和读取 UDID ......该死......我在我的愤怒哈哈哈...但问题仍然存在，以前有人遇到过这个问题吗？

更新

我向 Firebase 支持中心发送了一张票，他们告诉我 UDID 不在分发配置文件中，所以我的解决方案是重新创建配置文件，因为下载和导入临时配置文件不起作用。

此问题不是 Firebase 问题，而是与 iOS 签名地狱相关的经典问题。

正如在他们的网站上声称的那样,Gitlab可以用于在将一些代码推入存储库之后自动部署项目,但我无法弄清楚如何.有很多ruby教程,但没有流星或节点.

基本上我只需要在代码被推入我的主分支后重建我的服务器上的Docker容器.有谁知道如何实现它？我是.gitlab-ci.yml的新手,非常感谢帮助.