Mengotomatiskan Pembuatan Versi Semantik dengan Maven (SemVer GitFlow Maven)

Apakah Anda menggunakan pendekatan semantik untuk kontrol versi? Apakah Anda menggunakan gitflow? Anda kemungkinan besar akrab dengan proses menyesuaikan versi, membuat cabang, menggabungkan dari master / dev, menyesuaikan ulang versi, menangani konflik penggabungan, ...



Dalam artikel ini, saya akan menjelaskan secara singkat proses rilis yang pada dasarnya kami gunakan untuk perpustakaan kami dan cara kami mengotomatiskannya. Kami biasanya menggunakan pendekatan CI / CD menggunakan nomor build, tetapi untuk library kami, kami memilih untuk menggunakan versi semantik. Saya mengalami proses rilis yang membosankan yang menyertai ini di beberapa perusahaan dan sekarang saya akhirnya menemukan solusi.



Artikel ini tentang Maven, tetapi ada banyak alternatif selain Gradle .



Contoh proyek dapat ditemukan di halaman GitHub kami .



Versi semantik dan Git



Pembuatan versi semantik adalah sistem klasifikasi untuk rilis Anda. Saya yakin Anda pernah melihat nomor versi seperti 1.6.4, 1.7.10, 1.12.2 dan lainnya. Angka-angka ini adalah singkatan dari MAJOR.MINOR.PATCH (MAJOR.MINOR.PATCH)



Selain itu, ada versi SNAPSHOT yang terlihat sama, namun dengan penambahan "-SNAPSHOT" di bagian akhir, seperti 1.14.4-SNAPSHOT.



Proses rilis tipikal terdiri dari langkah-langkah berikut:



  1. Buat cabang rilis dari cabang pengembangan (selanjutnya disebut cabang pengembangan).
  2. Ubah versi di semua file pom.xml dari SNAPSHOT (1.2.3-SNAPSHOT) ke non-SNAPSHOT (1.2.3) di cabang rilis.
  3. Tingkatkan versi SNAPSHOT di cabang pengembangan (1.2.4-SNAPSHOT).
  4. Saat semuanya selesai untuk rilis, gabungkan cabang rilis ke cabang master. Ini adalah rilis terbaru.
  5. Gabungkan cabang master atau lepaskan cabang kembali ke cabang pengembangan.


/ , : , , .



, , . , merge .



?



  • , .
  • master SNAPSHOT.
  • CI, .
  • merge .
  • hotfixes ( master ).


gitflow-maven



, maven, pom.xml. . , .



, , . , . , : gitflow-maven-plugin.



, :



  • .
  • release .
  • hotfix.
  • (Merging) .


, . , CI/CD, , .



, (goals) maven. , .



:



, .



$ mvn gitflow:release-start -B


release (-B Batch Mode)



$ mvn gitflow:release


. master .



, , .



$ mvn gitflow:hotfix-start -B


$ mvn gitflow:hotfix-finish -B -DhotfixVersion=1.8.9b 


hotfix master , 1.8.9b . . - , .





, poms:



<build>
    <plugins>
        <plugin>
            <groupId>com.amashchenko.maven.plugin</groupId>
            <artifactId>gitflow-maven-plugin</artifactId>
            <version>1.13.0</version>
            <configuration>
                <!-- optional configuration -->
            </configuration>
        </plugin>
    </plugins>
</build>


GitHub maven central.



GitHub. :



<configuration>
    <!-- We use maven wrapper in all our projects instead of a local maven installation -->
    <mvnExecutable>./mvnw</mvnExecutable>

    <!-- Don’t push to the git remote. Very useful for testing locally -->
    <pushRemote>true</pushRemote>

    <!-- Set to true to immediately bump the development version when creating a release branch -->
    <commitDevelopmentVersionAtStart>false</commitDevelopmentVersionAtStart>

    <!-- Which digit to increas in major.minor.patch versioning, the values being 0.1.2 respectively.
         By default the rightmost number is increased.
         Pass in the number via parameter or profile to allow configuration,
         since everything set in the file can't be overwritten via command line -->
    <versionDigitToIncrement>${gitflowDigitToIncrement}</versionDigitToIncrement>

    <!-- Execute mvn verify before release -->
    <preReleaseGoals>verify</preReleaseGoals>
    <preHotfixGoals>verify</preHotfixGoals>

    <!-- Configure branches -->
    <gitFlowConfig>
        <productionBranch>master</productionBranch>
        <!-- default is develop, but we use development -->
        <developmentBranch>development</developmentBranch>
    </gitFlowConfig>
</configuration>


, , . , Gitlab CI.



Gitlab CI



CI/CD Gitlab CI , commit snapshot, merge master β€” release.



, β€” , master merge , hotfixes.



Gitlab CI, . :





release. , release, release, snapshot, (merge) master snapshot. - .



git Gitlab CI



git Gitlab CI, : , CI git.



write_repository. , , .



GITLAB_TOKEN, protected, development, release/* hotfix/* (protected). , .



git remote runner, CI . , Gitlab, :



$ git remote set-url --push origin "https://oauth2:${GITLAB_TOKEN}@${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git"


git . Git «», git. , git , . :



$ git config user.name "Gitlab CI"
$ git config user.email gitlab-ci@viesure.io


git, CI. .





, git CI, gitflow. .



, , :



Β· MINOR



Β· PATCH hotfixes



.



(goals) -B, , .



Release



$ ./mvnw gitflow: release -B -DgitflowDigitToIncrement = $RELEASE_DIGIT


. master SNAPSHOT , . (goal ) maven , .





$ ./mvnw gitflow: release-start -B -DgitflowDigitToIncrement = $RELEASE_DIGIT


$ git push origin HEAD


. , , , (, , ). , , .



$ git symbolic-ref refs/heads/$CI_COMMIT_REF_NAME refs/remotes/origin/$CI_COMMIT_REF_NAME
$ ./mvnw gitflow:release-finish -B -DgitflowDigitToIncrement=$RELEASE_DIGIT


release . Git ( ref) HEAD . Gitlab CI . HEAD . , , HEAD.



master , .



(Hotfix)



, , , , .



$ ./mvnw gitflow:hotfix-start -B -DgitflowDigitToIncrement=$HOTFIX_DIGIT
$ git push origin HEAD


Hotfix-start hotfix, .



$ export CURRENT_VERSION=${CI_COMMIT_REF_NAME/hotfix\/}
$ git symbolic-ref refs/heads/$CI_COMMIT_REF_NAME refs/remotes/origin/$CI_COMMIT_REF_NAME
$ ./mvnw gitflow:hotfix-finish -B -DgitflowDigitToIncrement=$HOTFIX_DIGIT -DhotfixVersion=$CURRENT_VERSION


Hotfix-finish master . : . , , . .



, hotfix-start , . , .



. , .





. , - !



, git CI runners . , , .



, . CI .



Gitlab CI GitHub.








All Articles