丨研發(fā)流程實(shí)戰(zhàn)iam項(xiàng)目是如何進(jìn)行管理的

為了向你演示流程，這里先假設(shè)一個(gè)場景。我們有一個(gè)需求：給IAM客戶端工具增加一 oworld命令，該命令向終端打 oworld接下來，我們就來看下如何具體去執(zhí)行研發(fā)流程中的每一步。首先，我們進(jìn)入開發(fā)階開發(fā)階段是開發(fā)者的場，完全由開發(fā)者來主導(dǎo)，它又可分為代碼開發(fā)和代碼提交兩個(gè)代碼開拿到需求之后，首先需要開發(fā)代碼。這時(shí)，我們就需要選擇一個(gè)適合團(tuán)隊(duì)和項(xiàng)目的Git工作流。因?yàn)镚itFlow工作流比較適合大型的非開源項(xiàng)目，所以這里我們選擇Gtlow工作流。代碼開發(fā)的具體步驟如下：第一步，基于develop分支，新建一個(gè)功能分 oworld1$gitcheckout-boworld這里需要注意：新建的branch名要符合GitFlow工作流中的分支命名規(guī)則。否則，在gitcommit階段，會(huì)因?yàn)閎ranch不規(guī)范導(dǎo)致commit失敗。IAM項(xiàng)目的分支命令規(guī)則IAM項(xiàng)目通過 mitgithooks來確保分支名是符合規(guī)范的。在IAM項(xiàng)目根 執(zhí)行g(shù)itcommit命令，git會(huì)自動(dòng)執(zhí)行 mit，該會(huì)檢查當(dāng)前的這里還有一個(gè)地方需要你注意：git不會(huì)提交.git/hooks下的githooks，所以我們需要通過以下，確保開發(fā)者clone倉庫之后，仍然能安裝我們指定的githooks到.git/hooks：12#Copygithookscriptswhenexecutecp-fgithooks/*上述代碼放在scri 命令時(shí)都會(huì)執(zhí)行，可以確保githooks都安裝到.git/hooks 第二步，在feature/ oworld分支中，完成 oworld命令的添加。首先，通過iamctl oworld命令創(chuàng) oworld命令模板代代12$iamctloworld-d Commandfilegenerated:接著，編輯internal/iamctl/cmd/cmd.go文件，在源碼文件中添 oworld(f,ioStreams),，加載 oworld命令。這里 oworld命令設(shè)置為TroubleshootingandDebuggingCommands命令分組123456789import(){Message:"TroubleshootingandDebuggingCommands:validate.NewCmdValidate(f,oworld(f,這些操作中包含了lowode的思想。在第10講中我就強(qiáng)調(diào)過，要盡可能使用代碼自動(dòng)生成這一技術(shù)。這樣做有兩個(gè)好處：一方面能夠提高我們的代碼開發(fā)效率；另一方面也能夠保證規(guī)范，減少手動(dòng)操作可能帶來的錯(cuò)誤。所以這里，我將iamcl令也模板化，并通過imctlnw自動(dòng)生成。第三步，生成代碼1$make如果改動(dòng)不涉及代碼生成，可以不執(zhí)行makegen操作。makegen執(zhí)行的其實(shí)gen.run目標(biāo)1gen.run:gen.cleangen.errcode可以看到，當(dāng)執(zhí)行makegen.run時(shí)，其實(shí)會(huì)先清理之前生成的文件，再分別自動(dòng)errorcodedoc.go件這里需要注意，通過makegen生成的存量代碼要具有冪等性。，才能確保每次我們可以將的與自動(dòng)生成代碼相關(guān)的功能放在gen.mkMakefile中。例如gen.docgo.doc，代表自動(dòng)生成doc.go文件gen.ca.%，代表自動(dòng)生成iamctl、iam-apiserver、iam-authz-server文件。 如果有新文件添加，我們還需要執(zhí)行makeverify-copyright，來檢查新文件有沒有添加頭信息。1$makeverify-如果檢查失敗，可以執(zhí)行makeadd-copyright自動(dòng)添加頭。添加信息只針這里還有個(gè)Makefile寫技巧：如果Makefilecommand要某個(gè)命令，就可以使該目標(biāo)依賴類似tools.verify.addlicense這種目標(biāo)，tools.verify.addlicense會(huì)檢查該工具12345678.PHONY:copyright.verifycopyright.verify:tools.verify.addlicense@if!which$*&>/dev/null;then$(MAKE)tools.install.$*;.PHONY:install.addlicense@$(GO)get-通過這種方式，可以使makecopyright.verify盡可能自動(dòng)化，減少手動(dòng)介入的概第五步，代碼格式化1$make執(zhí)行makeformat會(huì)依次執(zhí)行以下格式調(diào)用gofmt格式化你的代調(diào)用goimports工具，自動(dòng)增刪依賴的包，并將依賴包按字母序排序并分調(diào)用golines工具，把超過120行的代碼按golines規(guī)則，格式化成<120行的代碼1$make調(diào)用gomodedit-fmt格式化go.mod文件。1$make第七步，單元測(cè)試1$make1gotest`golist./...|egrep-v$(subst$(SPACE),'|',$(sort在go.test的command中，我們還運(yùn)行了以下命1sed-i'/mock_.*.go/d'運(yùn)行該命令的目的，是把mock_.*.go文件中的函數(shù)單元測(cè)試信息從coverage.out中刪除。mock_.*.go文件中的函數(shù)是不需要單元測(cè)試的，如果不刪除，就會(huì)影響后面的單元測(cè)如果想檢查單元測(cè)試覆蓋率，請(qǐng)執(zhí)代代1$make默認(rèn)測(cè)試覆蓋率至少 60%，也可以在命令行指定覆蓋率閾值為其他值，例如1$makecover如果測(cè)試覆蓋率不滿足要求，就會(huì)返回以下錯(cuò)誤信testcoverageistestcoveragedoesnotmeetexpectations:90%,pleaseaddtestmake[1]:***[go.test.cover]Errormake:***[cover]Error這里make命令的退出碼為1如果單元測(cè)試覆蓋率達(dá)不到設(shè)置的閾值，就需要補(bǔ)充測(cè)試用例，否則合并到develop和master分支。IAM項(xiàng)目配置了 ActionsCI自動(dòng)化流水線，CI流水線會(huì)自動(dòng)運(yùn)第八步，構(gòu)建最后，我們執(zhí)行makebuild命令，構(gòu)建出 下所有的二進(jìn)制安裝文件1$makemakebuild會(huì)自動(dòng)構(gòu)建cmd/ 件，可以傳入BINS選項(xiàng)，組件之間用空格隔開，并用雙引號(hào)引起來：11$makebuildBINS="iam-apiserver到這里，我們就完成了代碼開發(fā)階段的全如果你覺得手動(dòng)執(zhí)行的make命令比較多，可以直接執(zhí)行make命令123456789$===========>Generatingiamerrorcodegosource===========>Generatingerrorcode===========>Generatingmissingdoc.goforgo===========>Verifyingthe===========>Formatingteheadersforall===========>Rungolangcitolintsource===========>Rununit===========>Buildingbinaryiam-pumpv0.7.2-24-g5814e7bforlinux===========>Buildingbinaryiamctlv0.7.2-24-g5814e7bforlinux直接執(zhí)行make會(huì)執(zhí)行偽目標(biāo)all所依賴的偽目標(biāo)all:genadd-copyrightformatlintcoverbuild，也即執(zhí)行以下操作：生成代碼、自動(dòng)添加 這里你需要注意一點(diǎn)：all中依賴cover，cover實(shí)際執(zhí)行的是go.test.cover，而go.test.covergo.test，所以cover際上是先執(zhí)行單元測(cè)試，再檢查單元最后補(bǔ)充一點(diǎn)，在開發(fā)階段我們可以根據(jù)需要隨時(shí)執(zhí)行makegen、makeformatmakelint、makecover等操作，為的是能夠提前發(fā)現(xiàn)問題并改代碼提第一步，開發(fā)完后，將代碼提交到feature/ oworld分支，并push到遠(yuǎn)端倉庫。1123$gitaddoworld代$gitcommit-m"feat:addnewiamctlcommand$gitpushorigin oworld相關(guān)的改動(dòng)，這樣就知道一個(gè)commit做了哪些變更，方便以后追溯。所以，我不建議直接執(zhí)行g(shù)itadd.這類方式提交改動(dòng)。在提交commit時(shí)，commit-msggithooks會(huì)檢查commitmessage是否符合AngularCommitMessage規(guī)范，如果不符合會(huì)報(bào)錯(cuò)。commit-msage調(diào)用了 gitlint來檢查commitmessage。go-gitlint會(huì).gitlint中配置的commitmessage格式：1123IAM項(xiàng)目配置了 Actions，當(dāng)有代碼被push后，會(huì)觸發(fā)CI流水線，流水線會(huì)執(zhí)行makeall目標(biāo)。 ActionsCI流程執(zhí)行記錄如下圖：代123456name:-如果CI不通過，就需要修改代碼，直到CI流水線通過為代123456name:-7789types:[opened,runs-on:ubuntu-latestuses:name:Setupuses:actions/setup-go@v2go-version:name:allrun:可以看到 Actions實(shí)際上執(zhí)行了3步：拉取代碼、設(shè)置Go編譯環(huán)境、執(zhí)make令（也就是執(zhí)行makeall目標(biāo)）Actions也執(zhí)行了makeall目標(biāo)，和手動(dòng)操作執(zhí)行的makeall目標(biāo)保持一致，這樣做是為了讓線上的CI流程和本地的CI流程完全保持一致。這樣，當(dāng)我們?cè)诒镜貓?zhí)行make命令通過后，上也會(huì)通過。保持一個(gè)一致的執(zhí)行流程和執(zhí)行結(jié)果很重要。否則，本地執(zhí)行make通過，但是線上卻不通過，豈不很讓人頭疼？第二步，提交pullrequest登 ，基于 oworld創(chuàng)建pullrequest，并指定Reviewers進(jìn)codereview。具體操作如下圖當(dāng)有新的pullrequest被創(chuàng)建后，也會(huì)觸發(fā)CI流水線第三步，創(chuàng)建完pullrequest后，就可以通知reviewers來review代碼， 第四步，Reviewers對(duì)代碼進(jìn)行reviewReviewer通過reviewdiff后的內(nèi)容，并結(jié)合CI流程是否通過添加評(píng)論，并選擇Comment（僅評(píng)論）、Approve（通過）、RequestChanges（不通過，需要修改），如果review通過，feature發(fā)者可以直接在feature/oworld支修正代碼，push遠(yuǎn)端的feature/oworld支，然后通知reviewers次review。因?yàn)閜ush發(fā)生，所以會(huì)觸 ActionsCI流水線第五步，codereview通過后，maintainer就可以將新的代碼合并到develop分支使用Createamergecommit的方式，將pullrequest并到develop支，如下圖Createamergecommit的實(shí)際操作是gitmergeno-ff，feature/oworld支上所有的commit都會(huì)加到develop分支上，并且會(huì)生成一個(gè)mergecommit。使用第六步，合并到develop分支后，觸發(fā)CI流程到這里，開發(fā)階段的操作就全部完成了，整體流程如合并到develop分支之后，我們就可以進(jìn)入開發(fā)階段的下一階段，也就是測(cè)試階段在測(cè)試階段，開發(fā)人員主要負(fù)責(zé)提供測(cè)試包和修復(fù)測(cè)試期間發(fā)現(xiàn)的bug，這個(gè)過程中也可能會(huì)發(fā)現(xiàn)一些新的需求或變動(dòng)點(diǎn)，所以需要合理評(píng)估這些新的需求或變動(dòng)點(diǎn)是否要放在當(dāng)前迭代修改。測(cè)試階段的操作流程如下第一步，基于develop分支，創(chuàng)建release分支，測(cè)試代碼$gitcheckout-brelease/1.0.0$第二步，提交測(cè)試將release/1.0.0分支的代碼提交給測(cè)試同學(xué)進(jìn)試。這里假設(shè)一個(gè)測(cè)試失敗的場景：我們要求打印“oworld”，但打印的是“oWorld”，需要修復(fù)。那具體應(yīng)該怎么操作呢你可以直接在release/1.0.0分支修改代碼，修改完成后，本地構(gòu)建并提交代1234$$gitadd$gitcommit-m"fix:oworldprint$gitpushoriginpush到release/1.0.0后， Actions會(huì)執(zhí)行CI流水線。如果流水線執(zhí)行成功，就測(cè)試同學(xué)會(huì)對(duì)release/1.0.0支的代碼進(jìn)行充分的測(cè)試，例如功能測(cè)試、性能測(cè)試、集成第三步，測(cè)試通過后，將功能分支合并到master分支和develop分支$gitcheckout$gitmerge--no-ff$gitcheckout$gitmerge--no-ff$gittag-av1.0.0-m"addoworld"#master分支打到這里，測(cè)試階段的操作就基本完成了。測(cè)試階段的產(chǎn)物是master/develop支的代第四步，刪除feature/ oworld分支，也可以選擇性刪除release/1.0.0分支。我們的代碼都合并入master/develop分支后，feature開發(fā)者可以選擇是否要保feature。不過，如果沒有特別的原因，我建議刪掉，因?yàn)閒eature支太多的話，不僅看1$gitbranch-dIAMMakefile在上面的內(nèi)容中，我們以研發(fā)流程為主線，親身體驗(yàn)了IAM目的Makefile目管理功能。這些是你最應(yīng)該掌握的功能，但I(xiàn)AM項(xiàng)目的Makefile還有很多功能和設(shè)計(jì)技巧。接下來，我會(huì)給你一些很有價(jià)值的Makefile項(xiàng)目管理技巧。help自動(dòng)解因?yàn)殡S著項(xiàng)目的擴(kuò)展，Makefile大概率會(huì)不斷加入新的管理功能，這些管理功能也需要加入到makehelp輸出中。但如果每添加一個(gè)目標(biāo)，都要修改makehelp命令，就比較麻煩，還容易出錯(cuò)。所以這里，我通過自動(dòng)解析的方式，來生成makehelp輸出：##help:Showthishelp.PHONY:help:@echo-e"\nUsage:make<TARGETS><OPTIONS>@sed-n's/^##//p'$<|column-t-s':'|sed-e's/^/@echo目標(biāo)help令中，通過sed-n's/^##//p'$<|column-t-s':'|-es/^命令，自動(dòng)解析Makefile開頭的注釋行，從而自動(dòng)生成makehelp輸出。Options中指定變量通過以下賦值方式，變量可以在Makefileoptions中被指定ifeq($(originCOVERAGE:=例如，如果我們執(zhí)行make，則COVERAGE設(shè)置為默認(rèn)值60；如果我們執(zhí)行makeCOVERAGE=90，則COVERAGE值為90。通過這種方式，我們可以更靈活地控制Makefile的行為自動(dòng)生成一個(gè)項(xiàng)目最好有CHANGELOG用來展示每個(gè)版本之間的變更內(nèi)容，作為ReleaseNote的一部分。但是，如果每次都要手動(dòng)編寫CHANGELOG，會(huì)很麻煩，也不容易堅(jiān)持，所以這里我們可以借助git-chglog工具來自動(dòng)生成。IAMgit-chglogchglog下，在學(xué)習(xí)git-chglog自動(dòng)生成版本一個(gè)項(xiàng)目也需要有一個(gè)版本號(hào)，當(dāng)前用得比較多的是語義化版本號(hào)規(guī)范。但如果靠開發(fā)者手動(dòng)打版本號(hào)，工作效率低不說，經(jīng)常還會(huì)出現(xiàn)漏打、打的版本號(hào)不規(guī)范等問題。所以最好的辦法是，版本號(hào)也通過工具自動(dòng)生成。在IAM項(xiàng)目中，采用了gsemer工具來自動(dòng)生成版本號(hào)整 項(xiàng)目的版本號(hào)，都是通過scripts/ensure_tag.sh來生成的version=v`gsemverif[-z"`gittag-l$version`"gittag-a-m"releaseversion$version"在scripts/ensure_tag.sh中，通過gsemverbump命令來自動(dòng)化生成語義化的版本號(hào)，并執(zhí)行g(shù)ittag-a給倉庫打上版本號(hào)，gsemver命令會(huì)根據(jù)CommitMessage自動(dòng)生成版本號(hào)。之后，Makefile和S 用到的所有版本號(hào)均統(tǒng)一使用scripts/make-rules/common.mk文件中的VERSION變量：1VERSION:=gitdescribe--tags--always--上述的 命令通過gitdescribe來獲取離當(dāng)前提交最近的tag（版本號(hào)）在執(zhí)行g(shù)itdescribe時(shí)，如果符合條件的tag指向提交，則只顯示tag的名字，否則會(huì)有相關(guān)的后綴，來描述該tag之后有多少次提交，以及的提交commitid。例$gitdescribe--tags--always--這里解釋下版本號(hào)中各字符的含3：表示自打tagv1.0.0以來有3次提交g1909e47：g為git的縮寫，在多種管理工具并存的環(huán)境中很有用處1909e47：7位字符表示為提交的commitid前7位。--tags，不要只使用帶注釋的，而要使用refs/tags名稱空間中的任何--always，顯示唯一縮寫的提交對(duì)象作為后--match，只考慮與給定模式相匹配的保持行為一上面我們介紹了一些管理功能，例如CommitMessage否符合規(guī)范、自動(dòng)生成CHANGELOG、自動(dòng)生成版本號(hào)。這些可以通過Makefile操作，我們也可以手動(dòng)執(zhí)行。例如，通過以下命令，檢查IAM的所有Commit是否符合AngularCommitMessage規(guī)范：$go-b62db1f:subjectdoesnotmatchregex[^(revert:也可以通過以下命令，手動(dòng)來生成1$git-chglogv1.0.0CHANGELOG/CHANGELO