亚洲全黄无码一级在线看_国产剧情久久久性色_无码av一区二区三区无码_亚洲成a×人片在线观看

當(dāng)前位置: 首頁 > 科技新聞 >

GitLab 內(nèi)置了一個強(qiáng)大的 CI\u002FCD 系統(tǒng)

時間:2020-06-19 17:34來源:網(wǎng)絡(luò)整理 瀏覽:
GitLab CI/CD 是一個內(nèi)置在GitLab中的工具,用于通過持續(xù)方法進(jìn)行軟件開發(fā):Continuous Integration (C

GitLab CI/CD 是一個內(nèi)置在GitLab中的工具,用于通過持續(xù)方法進(jìn)行軟件開發(fā):

Continuous Integration (CI) 持續(xù)集成Continuous Delivery (CD) 持續(xù)交付Continuous Deployment (CD) 持續(xù)部署

持續(xù)集成的工作原理是將小的代碼塊推送到Git倉庫中托管的應(yīng)用程序代碼庫中,并且每次推送時,都要運(yùn)行一系列腳本來構(gòu)建、測試和驗(yàn)證代碼更改,然后再將其合并到主分支中。

持續(xù)交付和部署相當(dāng)于更進(jìn)一步的CI,可以在每次推送到倉庫默認(rèn)分支的同時將應(yīng)用程序部署到生產(chǎn)環(huán)境。

這些方法使得可以在開發(fā)周期的早期發(fā)現(xiàn)bugs和errors,從而確保部署到生產(chǎn)環(huán)境的所有代碼都符合為應(yīng)用程序建立的代碼標(biāo)準(zhǔn)。

GitLab CI/CD 由一個名為 .gitlab-ci.yml 的文件進(jìn)行配置,改文件位于倉庫的根目錄下。文件中指定的腳本由GitLab Runner執(zhí)行。

1. GitLab CI/CD 介紹

軟件開發(fā)的持續(xù)方法基于自動執(zhí)行腳本,以最大程度地減少在開發(fā)應(yīng)用程序時引入錯誤的機(jī)會。從開發(fā)新代碼到部署新代碼,他們幾乎不需要人工干預(yù),甚至根本不需要干預(yù)。

它涉及到在每次小的迭代中就不斷地構(gòu)建、測試和部署代碼更改,從而減少了基于已經(jīng)存在bug或失敗的先前版本開發(fā)新代碼的機(jī)會。

Continuous Integration(持續(xù)集成)

假設(shè)一個應(yīng)用程序,其代碼存儲在GitLab的Git倉庫中。開發(fā)人員每天都要多次推送代碼更改。對于每次向倉庫的推送,你都可以創(chuàng)建一組腳本來自動構(gòu)建和測試你的應(yīng)用程序,從而減少了向應(yīng)用程序引入錯誤的機(jī)會。這種做法稱為持續(xù)集成,對于提交給應(yīng)用程序(甚至是開發(fā)分支)的每項(xiàng)更改,它都會自動連續(xù)進(jìn)行構(gòu)建和測試,以確保所引入的更改通過你為應(yīng)用程序建立的所有測試,準(zhǔn)則和代碼合規(guī)性標(biāo)準(zhǔn)。

Continuous Delivery(持續(xù)交付)

持續(xù)交付是超越持續(xù)集成的更進(jìn)一步的操作。應(yīng)用程序不僅會在推送到代碼庫的每次代碼更改時進(jìn)行構(gòu)建和測試,而且,盡管部署是手動觸發(fā)的,但作為一個附加步驟,它也可以連續(xù)部署。此方法可確保自動檢查代碼,但需要人工干預(yù)才能從策略上手動觸發(fā)以必輸此次變更。

Continuous Deployment(持續(xù)部署)

與持續(xù)交付類似,但不同之處在于,你無需將其手動部署,而是將其設(shè)置為自動部署。完全不需要人工干預(yù)即可部署你的應(yīng)用程序。

1.1. GitLab CI/CD 是如何工作的

為了使用GitLab CI/CD,你需要一個托管在GitLab上的應(yīng)用程序代碼庫,并且在根目錄中的.gitlab-ci.yml文件中指定構(gòu)建、測試和部署的腳本。

在這個文件中,你可以定義要運(yùn)行的腳本,定義包含的依賴項(xiàng),選擇要按順序運(yùn)行的命令和要并行運(yùn)行的命令,定義要在何處部署應(yīng)用程序,以及指定是否 要自動運(yùn)行腳本或手動觸發(fā)腳本。

為了可視化處理過程,假設(shè)添加到配置文件中的所有腳本與在計(jì)算機(jī)的終端上運(yùn)行的命令相同。

一旦你已經(jīng)添加了.gitlab-ci.yml到倉庫中,GitLab將檢測到該文件,并使用名為GitLab Runner的工具運(yùn)行你的腳本。該工具的操作與終端類似。

這些腳本被分組到j(luò)obs,它們共同組成一個pipeline。一個最簡單的.gitlab-ci.yml文件可能是這樣的:

before_script:  - apt-get install rubygems ruby-dev -yrun-test:  script:    - ruby --version 6

before_script屬性將在運(yùn)行任何內(nèi)容之前為你的應(yīng)用安裝依賴,一個名為run-test的job(作業(yè))將打印當(dāng)前系統(tǒng)的Ruby版本。二者共同構(gòu)成了在每次推送到倉庫的任何分支時都會被觸發(fā)的pipeline(管道)。

GitLab CI/CD不僅可以執(zhí)行你設(shè)置的job,還可以顯示執(zhí)行期間發(fā)生的情況,正如你在終端看到的那樣:

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

為你的應(yīng)用創(chuàng)建策略,GitLab會根據(jù)你的定義來運(yùn)行pipeline。你的管道狀態(tài)也會由GitLab顯示:

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

最后,如果出現(xiàn)任何問題,可以輕松地回滾所有更改:

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

1.2. 基本 CI/CD 工作流程

一旦你將提交推送到遠(yuǎn)程倉庫的分支上,那么你為該項(xiàng)目設(shè)置的CI/CD管道將會被觸發(fā)。GitLab CI/CD 通過這樣做:

運(yùn)行自動化腳本(串行或并行) 代碼Review并獲得批準(zhǔn)構(gòu)建并測試你的應(yīng)用就像在你本機(jī)中看到的那樣,使用Review Apps預(yù)覽每個合并請求的更改 代碼Review并獲得批準(zhǔn)合并feature分支到默認(rèn)分支,同時自動將此次更改部署到生產(chǎn)環(huán)境如果出現(xiàn)問題,可以輕松回滾

通過GitLab UI所有的步驟都是可視化的:

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

1.3. 深入了解CI/CD基本工作流程

如果我們深入研究基本工作流程,則可以在DevOps生命周期的每個階段看到GitLab中可用的功能,如下圖所示:

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

1. Verify

通過持續(xù)集成自動構(gòu)建和測試你的應(yīng)用程序使用GitLab代碼質(zhì)量(GitLab Code Quality)分析你的源代碼質(zhì)量通過瀏覽器性能測試(Browser Performance Testing)確定代碼更改對性能的影響執(zhí)行一系列測試,比如Container Scanning , Dependency Scanning , JUnit tests用Review Apps部署更改,以預(yù)覽每個分支上的應(yīng)用程序更改

2. Package

用Container Registry存儲Docker鏡像用NPM Registry存儲NPM包用Maven Repository存儲Maven artifacts用Conan Repository存儲Conan包

3. Release

持續(xù)部署,自動將你的應(yīng)用程序部署到生產(chǎn)環(huán)境持續(xù)交付,手動點(diǎn)擊以將你的應(yīng)用程序部署到生產(chǎn)環(huán)境用GitLab Pages部署靜態(tài)網(wǎng)站僅將功能部署到一個Pod上,并讓一定比例的用戶群通過Canary Deployments訪問臨時部署的功能(PS:即灰度發(fā)布)在Feature Flags之后部署功能用GitLab Releases將發(fā)布說明添加到任意Git tag使用Deploy Boards查看在Kubernetes上運(yùn)行的每個CI環(huán)境的當(dāng)前運(yùn)行狀況和狀態(tài)使用Auto Deploy將應(yīng)用程序部署到Kubernetes集群中的生產(chǎn)環(huán)境

使用GitLab CI/CD,還可以:

通過Auto DevOps輕松設(shè)置應(yīng)用的整個生命周期將應(yīng)用程序部署到不同的環(huán)境安裝你自己的GitLab RunnerSchedule pipelines使用安全測試報(bào)告(Security Test reports)檢查應(yīng)用程序漏洞

2. GitLab CI/CD 快速開始

.gitlab-ci.yml文件告訴GitLab Runner要做什么。一個簡單的管道通常包括三個階段:build、test、deploy

管道在 CI/CD > Pipelines 頁面

2.1. 創(chuàng)建一個 .gitlab-ci.yml 文件

通過配置.gitlab-ci.yml文件來告訴CI要對你的項(xiàng)目做什么。它位于倉庫的根目錄下。

倉庫一旦收到任何推送,GitLab將立即查找.gitlab-ci.yml文件,并根據(jù)文件的內(nèi)容在Runner上啟動作業(yè)。

下面是一個Ruby項(xiàng)目配置例子:

 image: "ruby:2.5" before_script:   - apt-get update -qq && apt-get install -y -qq sqlite3 libsqlite3-dev nodejs   - ruby -v   - which ruby   - gem install bundler --no-document   - bundle install --jobs $(nproc)  "${FLAGS[@]}" rspec:   script:     - bundle exec rspec rubocop:   script:     - bundle exec rubocop


上面的例子中,定義里兩個作業(yè),分別是 rspec 和 rubocop,在每個作業(yè)開始執(zhí)行前,要先執(zhí)行before_script下的命令

2.2. 推送 .gitlab-ci.yml 到 GitLab

git add .gitlab-ci.ymlgit commit -m "Add .gitlab-ci.yml" git push origin master

2.3. 配置一個Runner

在GitLab中,Runner運(yùn)行你定義在.gitlab-ci.yml中的作業(yè)(job)

一個Runner可以是一個虛擬機(jī)、物理機(jī)、docker容器,或者一個容器集群

GitLab與Runner之間通過API進(jìn)行通信,因此只需要Runner所在的機(jī)器有網(wǎng)絡(luò)并且可以訪問GitLab服務(wù)器即可

你可以去 Settings ? CI/CD 看是否已經(jīng)有Runner關(guān)聯(lián)到你的項(xiàng)目,設(shè)置Runner簡單又直接

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

2.4. 查看 pipeline 和 jobs的狀態(tài)

在成功配置Runner以后,你應(yīng)該可以看到你最近的提交的狀態(tài)

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

為了查看所有jobs,你可以去 Pipelines ? Jobs 頁面

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

通過點(diǎn)擊作業(yè)的狀態(tài),你可以看到作業(yè)運(yùn)行的日志

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

回顧一下:

1、首先,定義.gitlab-ci.yml文件。在這個文件中就定義了要執(zhí)行的job和命令

2、接著,將文件推送至遠(yuǎn)程倉庫

3、最后,配置Runner,用于運(yùn)行job

3. Auto DevOps

Auto DevOps 提供了預(yù)定義的CI/CD配置,使你可以自動檢測,構(gòu)建,測試,部署和監(jiān)視應(yīng)用程序。借助CI/CD最佳實(shí)踐和工具,Auto DevOps旨在簡化成熟和現(xiàn)代軟件開發(fā)生命周期的設(shè)置和執(zhí)行。

借助Auto DevOps,軟件開發(fā)過程的設(shè)置變得更加容易,因?yàn)槊總€項(xiàng)目都可以使用最少的配置來完成從驗(yàn)證到監(jiān)視的完整工作流程。只需推送你的代碼,GitLab就會處理其他所有事情。這使得啟動新項(xiàng)目更加容易,并使整個公司的應(yīng)用程序設(shè)置方式保持一致。

下面這個例子展示了如何使用Auto DevOps將GitLab.com上托管的項(xiàng)目部署到Google Kubernetes Engine

示例中會使用GitLab原生的Kubernetes集成,因此不需要再單獨(dú)手動創(chuàng)建Kubernetes集群

本例將創(chuàng)建并部署一個從GitLab模板創(chuàng)建的應(yīng)用

3.1. 從GitLab模板創(chuàng)建項(xiàng)目

在創(chuàng)建Kubernetes集群并將其連接到GitLab項(xiàng)目之前,你需要一個Google Cloud Platform帳戶

下面使用GitLab的項(xiàng)目模板來創(chuàng)建一個新項(xiàng)目

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

給項(xiàng)目起一個名字,并確保它是公有的

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

3.2. 從GitLab模板創(chuàng)建Kubernetes集群

點(diǎn)擊 Add Kubernetes cluster 按鈕,或者 Operations > Kubernetes

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

安裝Helm, Ingress, 和 Prometheus

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

3.3. 啟用Auto DevOps (可選)

Auto DevOps 默認(rèn)是啟用的。

導(dǎo)航欄 Settings > CI/CD > Auto DevOps

勾選 Default to Auto DevOps pipeline

最后選擇部署策略

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

一旦你已經(jīng)完成了以上所有的操作,那么一個新的 pipeline 將會被自動創(chuàng)建。為了查看pipeline,可以去 CI/CD > Pipelines

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

3.4. 部署應(yīng)用

到目前為止,你應(yīng)該看到管道正在運(yùn)行,但是它到底在運(yùn)行什么呢?

管道內(nèi)部分為4個階段,我們可以查看每個階段有幾個作業(yè)在運(yùn)行,如下圖:

構(gòu)建 -> 測試 -> 部署 -> 性能測試

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

現(xiàn)在,應(yīng)用已經(jīng)成功部署,讓我們通過瀏覽器查看。

首先,導(dǎo)航到 Operations > Environments

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

在Environments中,可以看到部署的應(yīng)用的詳細(xì)信息。在最右邊有三個按鈕,我們依次來看一下:

第一個圖標(biāo)將打開在生產(chǎn)環(huán)境中部署的應(yīng)用程序的URL。這是一個非常簡單的頁面,但重要的是它可以正常工作!

緊挨著第二個是一個帶小圖像的圖標(biāo),Prometheus將在其中收集有關(guān)Kubernetes集群以及應(yīng)用程序如何影響它的數(shù)據(jù)(在內(nèi)存/ CPU使用率,延遲等方面)

GitLab 內(nèi)置了一個強(qiáng)大的 CI/CD 系統(tǒng)

第三個圖標(biāo)是Web終端,它將在運(yùn)行應(yīng)用程序的容器內(nèi)打開終端會話。

4. Examples

使用GitLab CI/CD部署一個Spring Boot應(yīng)用。

示例 .gitlab-ci.yml

 image: java:8 stages:   - build   - deploy before_script:   - chmod +x mvnw build:   stage: build   script: ./mvnw package   artifacts:     paths:       - target/demo-0.0.1-SNAPSHOT.jar production:   stage: deploy   script:   - curl --location "https://cli.run.pivotal.io/stable?release=linux64-binary&source=github" | tar zx   - ./cf login -u $CF_USERNAME -p $CF_PASSWORD -a api.run.pivotal.io   - ./cf push   only:   - master

5. Docs

https://about.gitlab.com/solutions/kubernetes/

https://docs.gitlab.com/ee/ci/README.html

https://docs.gitlab.com/ee/ci/introduction/

https://docs.gitlab.com/ee/topics/autodevops/

https://docs.gitlab.com/ee/ci/examples/README.html

推薦內(nèi)容