關(guān)于持續(xù)集成相關(guān)的概念，我是這次參加百人計(jì)劃才了解到的，原本還想著學(xué)習(xí)后把公司系統(tǒng)的測(cè)試環(huán)境部署到Linux下，自己慢慢折騰下，結(jié)果問(wèn)了下開(kāi)發(fā)，因我所在公司開(kāi)發(fā)語(yǔ)言用的是ASP.net，屬于老版本，都是在windows環(huán)境下部署的，如果用.net core來(lái)開(kāi)發(fā)，就可以進(jìn)行部署了，但是現(xiàn)有的系統(tǒng)得全部重做，對(duì)于傳統(tǒng)行業(yè)來(lái)說(shuō)，安全穩(wěn)定保守第一（開(kāi)發(fā)說(shuō)的）。
先普及下概念吧
持續(xù)集成Continuous integration：簡(jiǎn)稱CI，指的是頻繁地（一天多次）將代碼集成到主干，防止分支大幅偏離主干，主要解決以下問(wèn)題：
1、解放勞動(dòng)力
所有腳本都寫到Jenkins里，可實(shí)現(xiàn)一鍵構(gòu)建
P.S.有些公司開(kāi)發(fā)自己打包告知測(cè)試，這部分人員前途堪憂（只接觸到測(cè)試中間的功能執(zhí)行環(huán)節(jié)，很多流程的都沒(méi)接觸過(guò)，知識(shí)面過(guò)窄），而我是這其中的一員，想要以后混的好一點(diǎn)，必須趁著這2個(gè)月好好惡補(bǔ)下，希望能跟上進(jìn)度。
2、避免人為失誤
拷貝包出錯(cuò)、不小心刪了某個(gè)包、忘記kill進(jìn)程、文件編輯錯(cuò)誤等
3、提交效率
一般流程--包編譯、上傳、下載、傳服務(wù)器，耗時(shí)會(huì)比較久
4、質(zhì)量持續(xù)反饋
每日/時(shí)構(gòu)建，跑自動(dòng)化，自動(dòng)觸發(fā)自動(dòng)化腳本及監(jiān)控體系，（版本質(zhì)量、單元測(cè)試、代碼規(guī)范、接口自動(dòng)化、核心的GUI），每完成一點(diǎn)更新，就集成到主干，可以快速發(fā)現(xiàn)錯(cuò)誤，定位錯(cuò)誤也比較容易。有問(wèn)題開(kāi)發(fā)已經(jīng)收到報(bào)告，都不需要提交給測(cè)試
5、質(zhì)量保障
實(shí)時(shí)觸發(fā)自動(dòng)化接口，實(shí)時(shí)知道版本質(zhì)量
持續(xù)集成是針對(duì)一個(gè)團(tuán)隊(duì)的，成員有開(kāi)發(fā)、測(cè)試、運(yùn)維等。一般是質(zhì)量團(tuán)隊(duì)主導(dǎo)，測(cè)試團(tuán)隊(duì)能力不夠可找運(yùn)維協(xié)助（不排除很多成功的測(cè)試沒(méi)有代碼能力）。實(shí)際上持續(xù)集成要落地實(shí)施還是會(huì)存在很多障礙的，比如QA團(tuán)隊(duì)能力不夠，沒(méi)人懂代碼，這種情況可以采用內(nèi)部培養(yǎng)或者外部招聘 。
與持續(xù)集成相關(guān)的，還有兩個(gè)概念，分別是持續(xù)交付和持續(xù)部署。
持續(xù)交付（Continuous delivery）指的是，頻繁地將軟件的新版本，交付給質(zhì)量團(tuán)隊(duì)或者用戶，以供評(píng)審。如果評(píng)審?fù)ㄟ^(guò)，代碼就進(jìn)入生產(chǎn)階段。可以看作持續(xù)集成的下一步，它強(qiáng)調(diào)的是，不管怎么更新，軟件是隨時(shí)隨地可以交付的。
持續(xù)部署（continuous deployment）是持續(xù)交付的下一步，指的是代碼通過(guò)評(píng)審以后，自動(dòng)部署到生產(chǎn)環(huán)境。
前提：能自動(dòng)化完成測(cè)試、構(gòu)建、部署等步驟
目標(biāo)：代碼在任何時(shí)刻都是可部署的，可以進(jìn)入生產(chǎn)階段
持續(xù)部署（自動(dòng)觸發(fā)）與持續(xù)交付（手動(dòng)觸發(fā)）的區(qū)別，可以參考下圖
很明顯，持續(xù)集成有個(gè)必要條件--自動(dòng)化成熟度非常高
回憶下目前公司項(xiàng)目的流程
1、項(xiàng)目立項(xiàng)，明確需求（開(kāi)發(fā)點(diǎn)、測(cè)試點(diǎn)）
2、一系列的評(píng)審（設(shè)計(jì)評(píng)審、開(kāi)發(fā)文檔評(píng)審、測(cè)試用例評(píng)審等）
3、開(kāi)發(fā)編碼，提交測(cè)試
4、測(cè)試人員開(kāi)始測(cè)試，發(fā)現(xiàn)Bug，提交Bug
5、開(kāi)發(fā)修復(fù)，重新提交測(cè)試
6、測(cè)試驗(yàn)證
......
循環(huán)幾輪后，達(dá)到了上線的標(biāo)準(zhǔn)，相信很多人都會(huì)遇到開(kāi)發(fā)都沒(méi)有自測(cè)就提交了代碼，一些顯而易見(jiàn)的bug簡(jiǎn)單幾步操作就被測(cè)出來(lái)了，有些bug可能還會(huì)影響測(cè)試的進(jìn)度。
作為測(cè)試人員，希望簡(jiǎn)單的Bug 能越早發(fā)現(xiàn)，留更多的時(shí)間去挖掘嚴(yán)重/更深層的Bug，測(cè)試?yán)碚摳嬖V我們，越早發(fā)現(xiàn)Bug，修復(fù)Bug的代價(jià)也就越低。
那么如何實(shí)施呢？
有些代碼開(kāi)發(fā)很早就開(kāi)發(fā)完了，但是一直沒(méi)被測(cè)試，如果RD寫完部分功能就提交測(cè)試，那么測(cè)試自然就會(huì)提前開(kāi)始，相對(duì)來(lái)說(shuō)能較早的發(fā)現(xiàn)Bug。這時(shí)就體現(xiàn)出持續(xù)集成的優(yōu)勢(shì)了，每次集成都通過(guò)自動(dòng)化的構(gòu)建（包括編譯，發(fā)布，自動(dòng)化測(cè)試）來(lái)驗(yàn)證，從而盡早地發(fā)現(xiàn)集成錯(cuò)誤。
本次課程分享的是用Jenkins作為持續(xù)集成工具來(lái)實(shí)戰(zhàn)
Jenkins是基于Java開(kāi)發(fā)的一種持續(xù)集成工具，用于監(jiān)控持續(xù)重復(fù)的工作。我們可以把Jenkins想象成一個(gè)框架，想讓它做什么它就能做什么，前提是安裝它需要的插件，或者用shell / python手動(dòng)寫腳本。
Jenkins能提供詳細(xì)的日志文件和提醒功能，還能用圖表的形式形象地展示項(xiàng)目構(gòu)建的趨勢(shì)和穩(wěn)定性，用戶界面設(shè)計(jì)的很簡(jiǎn)單，也比較實(shí)用，文檔很完善，還有很豐富的插件，比較容易上手。
