DevOps: 項目多環境配置和健康檢查

DevOps


DevOps是Development和Operations的組合詞,做爲一名軟件工程師或者系統架構師,對於系統的開發和部署須要有充分的瞭解和把控。html

下面咱們經過一個故事,把軟件發佈中的分環境配置和版本檢查的解決方案爲你娓娓道來......java

本文涉及到的全部代碼能夠在這裏 👉 maven-devops 獲取。git

一個故事(事故)

試想這樣一個場景,你作了一個功能: 天天凌晨4點去某個系統拉取一份數據郵件,而後次日上午6點以郵件的形式發給你的老闆。github

首先你在本身的電腦上開發和測試,確認開發完成之後,把代碼打包放到測試服務器上跑了一下。web

你找到可愛的測試小妹妹,通過嚴格的測試,確認經過了全部測試用例。最後你不忘恭維一下測試小妹妹最近燙的頭髮真漂亮,並含蓄地表示有空想請她看最近上映的漫威電影。( 而實際上測試小妹妹的頭髮沒有燙過,她也沒聽懂你的暗示,她更不喜歡看漫威的電影,最最關鍵的是,你根本沒有時間請別人看電影——這個問題問一下你家裏洗衣機裏靜靜趟了兩星期的襪子就知道了。)spring

你把本身的代碼合併到主分支,而後通知發佈人員把代碼發佈到生產環境。當你收到運維人員發佈成功的提醒的時候,擡頭看看錶已是午夜兩點了。你喝乾淨杯子裏的咖啡,深深懶腰,搭車回家了。shell

次日上午,你在一陣急促的電話鈴聲中被吵醒,電話那頭的聲音頓時讓你睏意全無:老闆沒有收到任何郵件,郵件裏的資料要在2h之後的一個重要會議中使用!數據庫

......apache

數據終因而千方百計搞到了,但疲憊、恐懼、羞恥和自責已經淹沒了你的頭腦,你要搞事情了:查到緣由,完全解決這個問題!json

笨人和聰明人的差別就在於,笨人只會不停地栽跟頭,而聰明人跌倒之後爬起來,不忘把坑填上,還會在旁邊立個碑,以警後人 —— 能作到這一點的幾乎就是偉人了。

分環境

前面提到了你本身開發、給測試小妹妹測試以及給運維人員發佈,一共三個環境,而實際上一個軟件系統的環境每每不止這些。

經常使用的環境有:dev、sit、uat、sandbox、pro。

  • dev就是開發環境(Development Environment),每一個開發人員本身搭建的環境,固然通常也會在公司內部服務器搭建一些諸如數據庫、分佈式服務等公用的開發環境服務。

  • sit就是系統集成測試環境(System Integration Testing Environment),主要目的是把系統的各個模塊做爲一個組進行測試。

  • uat就是用戶驗收測試環境(User Acceptance Testing Environment),通常是對系統比較熟悉的人,對開發成果進行驗收的環境。

  • sandbox就是沙箱環境(Sandbox Environment),這個環境爲的是最真實地模擬生產環境。

  • pro就是生產環境(Production Environment),這個環境是咱們最終交付的產品所運行的環境。

爲何要有這麼多環境呢?答案是形勢所迫。隨着軟件開發的分工日益精細化和軟件系統的日益複雜化,不一樣環境所承擔的職責不一樣,但最終目的是同樣的:提升效率、保證質量、節約成本、保證收益。

關於分環境的思想這裏就很少講了,下面要講的一個問題是分環境是如何實現的?

分環境的實現方式有不少Spring Profile、Spring Boot等等都有不一樣的實現。

下面講一個使用 maven profiles 實現分環境配置的方式。

分環境實現

好比我在不一樣的環境須要提供不一樣的配置文件,怎麼實現呢?

首先在pom.xml增長以下幾個環境的配置,並指定配置路徑:

<profiles>

    <!-- 分環境profile> -->
    <profile>
        <id>dev</id>
        <!-- 若是dev帶上activeByDefault,會默認將dev下的配置複製到config目錄下-->
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
            <env>dev</env>
            <package.target>dev</package.target>
            <spring.profiles.active.value>dev</spring.profiles.active.value>
            <yui.skip>true</yui.skip>
            <config.path>src/main/resources/config/dev</config.path>
        </properties>
    </profile>

    <!--sit-->
    <profile>
        <id>sit</id>
        <properties>
            <env>sit</env>
            <package.target>sit</package.target>
            <spring.profiles.active.value>sit</spring.profiles.active.value>
            <yui.skip>false</yui.skip>
            <config.path>src/main/resources/config/sit</config.path>
        </properties>
    </profile>

    <!-- uat -->
    <profile>
        <id>uat</id>
        <properties>
            <env>uat</env>
            <package.target>uat</package.target>
            <spring.profiles.active.value>uat</spring.profiles.active.value>
            <yui.skip>false</yui.skip>
            <config.path>src/main/resources/config/uat</config.path>
        </properties>
    </profile>

    <!--sandbox-->
    <profile>
        <id>sandbox</id>
        <properties>
            <env>sandbox</env>
            <package.target>sandbox</package.target>
            <spring.profiles.active.value>sandbox</spring.profiles.active.value>
            <yui.skip>false</yui.skip>
            <config.path>src/main/resources/config/sandbox</config.path>
        </properties>
    </profile>

    <!--prod-->
    <profile>
        <id>prod</id>
        <properties>
            <env>prod</env>
            <package.target>prod</package.target>
            <spring.profiles.active.value>prod</spring.profiles.active.value>
            <yui.skip>false</yui.skip>
            <config.path>src/main/resources/config/prod</config.path>
        </properties>
    </profile>

</profiles>
複製代碼

而後在打包項目的時候經過-P參數指定環境就好了。例如打包uat環境:

$ mvn install -Puat
複製代碼

指定環境打包的缺點

首先就是慢,也可說浪費咖啡。不少大型項目每次從編譯到拉文件都要半個多小時。

那怎麼節省發佈的時間,讓咱們早點下班呢?答案就是全部環境一個包。

5個環境就能節省2個小時,太值了!

只打一個包

怎麼全部環境一個包呢?

首先在pom.xml配置maven-resources-plugin插件,並指定copy-resources的路徑,把全部環境的配置都打到包裏。

<!-- maven-resources-plugin -->
 <plugin>
     <artifactId>maven-resources-plugin</artifactId>
     <version>2.6</version>
     <executions>
         <execution>
             <id>copy-resources</id>
             <phase>validate</phase>
             <goals>
                 <goal>copy-resources</goal>
             </goals>
             <configuration>
                 <outputDirectory>${basedir}/target/classes/config</outputDirectory>
                 <resources>
                     <resource>
                         <directory>${config.path}/</directory>
                         <filtering>true</filtering>
                     </resource>
                 </resources>
             </configuration>
         </execution>
     </executions>
 </plugin>
複製代碼

而後正常使用mvn install打包。

最後把要發佈的包複製到指定環境機器的磁盤上之後,經過mv命令把須要發佈的環境的配置移動出來。例如發佈sandbox環境:

mv config/sandbox/* config/
複製代碼

固然這個操做不是必須的,好比你在啓動容器的時候指定了當前的環境,而後經過${spring.profile.active}來指定當前讀取哪一個目錄下的配置也能夠。

git分支管理

根據每一個環境打不一樣的包,發佈一個新的feature到生產須要相似下面這樣的流程:

  1. 首先用 develop 分支 打包,發佈sit環境,測試經過合併到 release 分支;
  2. 而後用 release 分支 打包,發佈到uat環境,測試經過合併到 master 分支(打 tag);
  3. 最後用 master 分支 打包,發佈到生產環境。 開發只能在 develop分支和feature分支改代碼,master分支與線上運行的代碼保持一致。

打一個包發佈全部環境之後,分支管理模式將改成:

  1. 功能在feature分支自測成功之後,將代碼合併到release分支,測試人員在release分支測試並最終發佈生產。
  2. 當代碼成功發佈生產之後,將release分支代碼合併到master 分支。

上圖演示了多環境多包發佈多環境單包發佈的簡要流程,下面作一下補充說明。

多環境多包發佈

  1. 每一個環境分別打包發佈,直至最後全部環境測試經過發佈生產。
  2. 最後將master分支的代碼merge到develop分支,保證develop分支的代碼與線上代碼一致。

多環境單包發佈

  1. 只在release分支打一個包,供全部環境發佈。測出bug則從新打包,直至全部bug都測試經過。
  2. 使用release分支打的包發佈成功之後,會將release分支的代碼merge到master分支備份,方便往後hotfix等。
  3. 最後將master分支的代碼merge到develop分支,保證develop分支的代碼與線上代碼一致。

版本檢查

如今解決了打包慢的問題,可是怎麼保證運維人員發佈的代碼版本跟咱們功能所在的版本一致呢?

固然能夠口頭確認,結果就發生了上面的「慘案」。

那麼咱們能不能本身檢查呢?那就要藉助工具了。

git-commit-id-plugin

git-commit-id-plugin是一個插件,會根據當前分支的版本號生成一個git.properties文件。

首先在pom.xml引入插件配置:

<!-- https://github.com/git-commit-id/maven-git-commit-id-plugin -->
<plugin>
   <groupId>pl.project13.maven</groupId>
   <artifactId>git-commit-id-plugin</artifactId>
   <version>${git-commit-id-plugin.version}</version>
   <executions>
       <execution>
           <id>get-the-git-infos</id>
           <goals>
               <goal>revision</goal>
           </goals>
       </execution>
   </executions>
   <configuration>
       <!-- 使properties擴展到整個maven bulid 週期, Ref: https://github.com/ktoso/maven-git-commit-id-plugin/issues/280 -->
       <injectAllReactorProjects>true</injectAllReactorProjects>
       <dateFormat>yyyy.MM.dd HH:mm:ss</dateFormat>
       <verbose>true</verbose>
       <!-- 是否生 git.properties 屬性文件 -->
       <generateGitPropertiesFile>true</generateGitPropertiesFile>
       <!--git描述配置,可選;由JGit提供實現; -->
       <gitDescribe>
           <!--是否生成描述屬性 -->
           <skip>false</skip>
           <!--提交操做未發現tag時,僅打印提交操做ID -->
           <always>false</always>
           <!--提交操做ID顯式字符長度,最大值爲:40;默認值:7; 0表明特殊意義;-->
           <abbrev>7</abbrev>
           <!--構建觸發時,代碼有修改時(即"dirty state"),添加指定後綴;默認值:""; -->
           <dirty>-dirty</dirty>
           <forceLongFormat>false</forceLongFormat>
       </gitDescribe>
   </configuration>
</plugin>
複製代碼

接着打包項目,你就能夠看到本身編譯的文件下面多了一個git.properties文件:

#Generated by Git-Commit-Id-Plugin
#Sat Apr 20 13:08:01 CST 2019
git.branch=master
git.build.host=DESKTOP-12GT5DQ
git.build.time=2019.04.20 13\:08\:01
git.build.user.email=ijiangtao@foxmail.com
git.build.user.name=ijiangtao
git.build.version=1.1.01.01-SNAPSHOT
git.closest.tag.commit.count=
git.closest.tag.name=
git.commit.id=67b60eeffa9deca877c2b9a28d52a40d3ea55444
git.commit.id.abbrev=67b60ee
git.commit.id.describe=67b60ee
git.commit.id.describe-short=67b60ee
git.commit.message.full=\u53D1\u9001\u91CD\u8981\u6570\u636E\u7ED9\u8001\u677F~~~~
git.commit.message.short=\u53D1\u9001\u91CD\u8981\u6570\u636E\u7ED9\u8001\u677F~~~~
git.commit.time=2019.04.20 12\:57\:50
git.commit.user.email=ijiangtao@foxmail.com
git.commit.user.name=ijiangtao
git.dirty=false
git.remote.origin.url=https\://github.com/javastudydemo/jsd-maven.git
git.tags=
git.total.commit.count=2
複製代碼

有了這個文件,咱們就能夠清晰地知道生產環境的代碼是什麼版本了。

須要特別注意的是,使用這個插件要保證你編譯的項目是有.git目錄的,由於這個插件要獲取git的提交信息,若是不使用git進行版本管理的項目,編譯會報錯。

版本檢查地址

下面提供一個Controller來展現git的提交信息。

package net.ijiangtao.tech.maven.web.controller;

import com.alibaba.fastjson.JSON;
import com.alibaba.fastjson.serializer.SerializerFeature;
import com.wordnik.swagger.annotations.Api;
import com.wordnik.swagger.annotations.ApiOperation;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

import java.util.*;

import static org.apache.commons.lang3.ObjectUtils.defaultIfNull;

/** * @author ijiangtao */
@Controller
@Api(value = "", description = "git info from git-commit-id-plugin")
public class GitCommitController {

    /** * @return */
    @RequestMapping("/git/commit/info")
    @ResponseBody
    @ApiOperation(value = "get commit info", httpMethod = "GET")
    public String showGitCommitInfo() {
        //git.properties
        ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));

        Map<String, String> map = new TreeMap<>();

        Enumeration<String> keysEnumeration = resourceBundle.getKeys();

        while (keysEnumeration.hasMoreElements()) {
            String key = keysEnumeration.nextElement();

            map.put(key, resourceBundle.getString(key));
        }

        return JSON.toJSONString(map, SerializerFeature.PrettyFormat);
    }

    /** * @return */
    @ApiOperation(value = "get commit id", httpMethod = "GET")
    @RequestMapping("/git/commit/id")
    @ResponseBody
    public String showGitCommitId() {
        //git.properties
        ResourceBundle resourceBundle = ResourceBundle.getBundle("git", defaultIfNull(null, Locale.getDefault()));
        return resourceBundle.getString("git.commit.id");
    }


}
複製代碼

經過Jetty插件啓動項目,並訪問SwaggerUI地址 http://localhost:8241/swagger/index.html ,最後經過http://localhost:8241/git/commit/info請求到了咱們的git提交信息。

DevOps

通常咱們爲了版本回滾的方便,發佈的時候會經過git commit id進行打包,能夠經過機器對比二者是否一致,達到自動檢查的目的,而不是每次須要人工檢查。

總結

本文講解了使用Maven進行分環境配置和進行發佈版本檢查的一種實現模式,在持續集成/持續部署(CI/CD)的實踐中很是有借鑑意義。

相關資源

相關文章
相關標籤/搜索