背景
问题
问题一：
持续集成指的是，频繁地（一天多次）将代码集成到主干。
（1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。（2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。"
持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。
持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。持续部署的前提是能自动化完成测试、构建、部署等步骤。
问题二：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
问题三：
stages:- build- test- deploy# 定义 job（任务）job1:stage: testtags:- XX #只有标签为XX的runner才会执行这个任务only:- dev #只有dev分支提交代码才会执行这个任务。也可以是分支名称或触发器名称- /^future-.*$/ #正则表达式，只有future-开头的分支才会执行script:- echo "I am job1"- echo "I am in test stage"# 定义 jobjob2:stage: test #如果此处没有定义stage，其默认也是testonly:- master #只有master分支提交代码才会执行这个任务script:- echo "I am job2"- echo "I am in test stage"allow_failure: true #允许失败，即不影响下步构建# 定义 jobjob3:stage: buildexcept:- dev #除了dev分支，其它分支提交代码都会执行这个任务script:- echo "I am job3"- echo "I am in build stage"when: always #不管前面几步成功与否，永远会执行这一步。它有几个值：on_success （默认值）on_failurealwaysmanual（手动执行）# 定义 job.job4: #对于临时不想执行的job，可以选择在前面加个"."，这样就会跳过此步任务，否则你除了要注释掉这个jobj外，还需要注释上面为deploy的stagestage: deployscript:- echo "I am job4"# 模板，相当于公用函数，有重复任务时很有用.job_template: &job_definition # 创建一个锚，'job_definition'image: ruby:2.1services:- postgres- redistest1:<<: *job_definition # 利用锚'job_definition'来合并script:- test1 projecttest2:<<: *job_definition # 利用锚'job_definition'来合并script:- test2 project#下面几个都相当于全局变量，都可以添加到具体job中，这时会被子job的覆盖before_script:- echo "每个job之前都会执行"after_script:- echo "每个job之后都会执行"variables: #变量DATABASE_URL: "postgres://postgres@postgres/my_database" #在job中可以用${DATABASE_URL}来使用这个变量。常用的预定义变量有CI_COMMIT_REF_NAME（项目所在的分支或标签名称），CI_JOB_NAME（任务名称），CI_JOB_STAGE（任务阶段）GIT_STRATEGY: "none" #GIT策略，定义拉取代码的方式，有3种：clone/fetch/none，默认为clone，速度最慢，每步job都会重新clone一次代码。我们一般将它设置为none，在具体任务里设置为fetch就可以满足需求，毕竟不是每步都需要新代码，那也不符合我们测试的流程cache: #缓存#因为缓存为不同管道和任务间共享，可能会覆盖，所以有时需要设置keykey: ${CI_COMMIT_REF_NAME} # 启用每分支缓存。#key: "$CI_JOB_NAME/$CI_COMMIT_REF_NAME" # 启用每个任务和每个分支缓存。需要注意的是，如果是在windows中运行这个脚本，需要把$换成%untracked: true #缓存所有Git未跟踪的文件paths: #以下2个文件夹会被缓存起来，下次构建会解压出来- node_modules/- dist/
stages:- buildvariables: # 定义用到的变量PROJECT_NAME: xxx.test# 需要发送的安全依赖文件 pom.xmlDEPEND_FILE: pom.xmlbuild:stage: buildtags:- shared-shellscript:# 执行操作：发送依赖文件pom及对应的commit id 、owner，传给三方库漏洞检测服务进行检测及通知owner- file=` $DEPEND_FILE `- echo {”owner":"$GITLAB_USER_EMAIL"，"app_name":"$PROJECT_NAME","branch":"$CI_COMMIT_BRANCH","commit_id":"$CI_COMMIT_SHA","lang":"java","app_from":"git","data":"$file","build_task_id":"$CI_JOB_ID"}only:- branches- tags
本文始发于微信公众号（哔哩哔哩安全应急响应中心）：漫谈SDL之三方库漏洞检测与CICD
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论