我正试图在一个我们目前没有足够能力来对所有提交运行所有测试的组织中引入持续交付。下面是一个简化的,虚构的场景,其中包含数字,以说明问题。
想象一下上面的管道。我们有能力在所有提交上运行提交阶段,部分是因为它被设计为可以快速运行,部分是因为我们模拟了环境中所有昂贵的部分,因此它不需要任何昂贵的硬件即可运行。实际上,我什至可以在笔记本电脑上本地运行它。
另一方面,验收测试需要大约6个小时来执行,并且随着我们引入更多需要测试的功能,时间不断增加。他们在像环境这样的生产环境中工作,该环境每年花费100万美元,所以我们只能得到其中的一个。
我们每天大约有20次提交,并且通常都在办公时间内完成,因此,实际上,在白天,我们可以对第一个提交,最后一个提交以及在提交之后6个小时内发生的提交进行验收测试。第一次提交。根本不可能对每个提交都运行验收测试。
今天,提交阶段是在每个提交上运行其自己的工作,验收测试在每晚运行的另一个工作中进行,部署到生产是手动过程,然后进行大量的手动测试。验收测试总是坏的。版本不是由主版本发布的,而是由候选发布的分支组成的,在发布之前,这些分支经过了至少一个月的测试和错误修复。有时我们甚至有时会同时进行多个操作,因为一个发行版在下一个计划发行版开始之前没有完成。
我非常想通过引入持续的交付渠道来修复我们的发布流程中断。我目前还没有针对缺乏容量的解决方案,但是根据容量跳过阶段似乎是一种前进的道路。考虑到詹金斯的灵活性,我真的不怀疑这样做是否可行,但是我正在努力寻找有关如何做的资源。我在流水线中使用(
when
对跳过代码进行了硬编码,以生成屏幕截图,因此请勿以此为证据证明我已经解决了问题。
请记住,黄色框中的所有内容都是虚构的,但问题是真实的:
如何根据能力跳过Jenkins中的阶段?
答案 0 :(得分:0)
在詹金斯中基于容量来跳过阶段的方法是使用lock
和milestone
的组合:
pipeline {
agent none
stages {
stage('Commit Stage') {
steps {
sleep 10
}
}
stage('Acceptance Tests') {
steps {
milestone(1)
lock(resource: "staging", inversePrecedence: true) {
milestone(2)
sleep 20
}
}
}
stage('Deploy to Production') {
steps {
sleep 10
}
}
}
}
通过使用inversePrecedence
锁,最新版本将首先获得该锁,因此将成为第一个通过里程碑2的锁。然后,所有已通过里程碑1的较早版本都将中止。通过省略里程碑1,较早的版本在获得锁定之前将不会被中止,这可能会永远发生。
只需用实际工作代替睡眠,您将获得问题中所述的管道。
我还应该提到,建议在agent none
的阶段中获取锁,因为这样等待的作业将不会占用执行者。可能会获得多个阶段的锁定,并且每个阶段都可以在不同的代理上执行。
编辑:经过更多的实验,我意识到自己做错了。显然,在获取锁之前和之后,您需要一个milestone
。仅仅拥有一个就会导致构建问题永远无法完成。我在阅读以下博客文章后发现了问题:https://jenkins.io/blog/2016/10/16/stage-lock-milestone/