Cara mengautomasikan versi dan keluaran projek dengan penggunaan berterusan

Menggunakan kawalan versi semantik boleh memudahkan untuk mengekalkan dan menyampaikan perubahan perisian, tetapi operasi manual adalah rumit. Walaupun anda secara manual menggabungkan PR, tandakan penyerahan dan menolak pelepasan, anda masih perlu menulis keterangan pelepasan. Terdapat banyak langkah, pengulangan yang tinggi, memakan masa dan intensif buruh.

Artikel ini akan menerangkan bagaimana untuk mencapai proses yang lebih cekap dan mengautomasikan proses pelepasan sepenuhnya dengan mengintegrasikan versi semantik ke dalam proses penempatan yang berterusan.

Kawalan versi semantik

Versi semantik adalah nombor versi yang terdiri daripada tiga nombor, seperti 1.4.10. Setiap nombor mempunyai makna tertentu:

Perubahan versi utama (Major)

Nombor pertama menunjukkan perubahan versi utama, yang bermaksud terdapat perubahan yang merosakkan.

Perubahan versi kecil (kecil)

Nombor kedua menunjukkan perubahan versi kecil, yang bermaksud bahawa ciri -ciri baru telah ditambah.

Perubahan versi patch

Nombor ketiga menunjukkan perubahan versi yang ditampal, yang bermaksud pepijat ditetapkan.

Versi semantik dapat difahami dengan lebih ringkas sebagai: perubahan merosakkan, perubahan fungsional, dan pembetulan pepijat. Keterangan ini lebih tepat dan mengelakkan kekaburan.

Hantar format maklumat

Untuk memastikan bahawa nombor versi semantik ditambah dengan betul dan versi yang betul dikeluarkan, format maklumat penyerahan standard diperlukan. Format maklumat penyerahan piawai membantu menentukan masa untuk meningkatkan nombor dan mudah menghasilkan arahan penerbitan. Di sini, sudut akan digunakan untuk mengemukakan konvensyen maklumat, dan sudah tentu ia juga boleh diubah seperti yang diperlukan.

Formatnya adalah seperti berikut:

<code></code>

Setiap penyerahan mengandungi tajuk , badan , dan nota kaki .

Hantar tajuk

Tajuknya adalah suatu keharusan, ia mempunyai format khas termasuk jenis , skop pilihan dan topik .

Jenis tajuk adalah medan yang diperlukan untuk menggambarkan kesan penyerahan pada versi seterusnya. Ia mestilah salah satu jenis berikut:

• Feat : Ciri -ciri Baru
• Betulkan : Pembetulan pepijat
• Dokumen : perubahan dokumen
• Gaya : Perubahan yang tidak mempengaruhi makna kod (contohnya: ruang, format, titik titik tinggi, dll.)
• Refactor : Refactoring kod, tidak menetapkan pepijat atau menambah fungsi
• Perf : Penambahbaikan Prestasi
• ujian : tambah atau ujian betul
• Kerja : Perubahan untuk membina proses atau alat bantu dan perpustakaan, seperti menjana dokumen

Skop adalah harta pengumpulan yang menentukan subsistem yang mengemukakan yang berkaitan dengan subsistem, seperti API, papan pemuka aplikasi, atau akaun pengguna, dan lain -lain. Jika beberapa subsistem diubahsuai oleh komit, asterisk (*) boleh digunakan sebaliknya.

Topik tajuk harus menerangkan secara ringkas perubahan yang dibuat. Peraturan berikut diperlukan semasa menulis topik:

• Gunakan ayat -ayat yang penting, tegang sekarang (mis., "Berubah" dan bukannya "berubah" atau "berubah").
• Huruf kecil huruf awal.
• Tiada tempoh (.) Ditambah pada akhir.
• Elakkan panjang topik melebihi 80 aksara. Hantar badan.

Seperti tema tajuk, teks utama juga harus menggunakan ayat -ayat yang penting, tegang sekarang. Ia harus termasuk motivasi untuk perubahan dan membandingkannya dengan tingkah laku sebelumnya.

Hantar nota kaki

Nota kaki harus mengandungi sebarang maklumat mengenai perubahan yang merosakkan dan juga di mana soalan yang disebutkan untuk penyerahan ini ditutup.

Maklumat perubahan yang merosakkan harus bermula dengan perubahan pecah: diikuti dengan ruang atau dua baris baru. Maklumat penyerahan yang tersisa di sini.

Menguatkuasakan format maklumat penyerahan

Dalam kerja berpasukan, menyeragamkan apa sahaja yang perlu diikuti oleh semua orang adalah sentiasa menjadi cabaran. Untuk memastikan semua orang menggunakan kriteria penyerahan yang sama, kami akan menggunakan Commitizen.

Commitizen adalah alat baris arahan yang memudahkan proses menggunakan format mesej komit yang konsisten. Membuat repositori yang serasi dengan Commitizen bermakna sesiapa di dalam pasukan boleh menjalankan Git CZ dan mendapatkan arahan terperinci untuk mengisi maklumat penyerahan.

Menjana dan menerbitkan

Sekarang kita tahu bahawa penyerahan kami mengikuti piawaian yang konsisten, kita boleh mula menghasilkan siaran dan nota pelepasan. Untuk melakukan ini, kami akan menggunakan pakej yang dipanggil Semantik-Release. Ini adalah pakej yang diselenggarakan dengan baik untuk pelbagai platform integrasi berterusan (CI).

Pelepasan semantik adalah kunci kepada perjalanan kami, kerana ia akan melaksanakan semua langkah yang diperlukan untuk dibebaskan, termasuk:

1. Sahkan versi terakhir yang anda keluarkan
2. Tentukan jenis penerbitan berdasarkan penyerahan yang ditambahkan sejak pelepasan terakhir
3. Menjana arahan penerbitan untuk penyerahan yang ditambahkan sejak pelepasan terakhir
4. Kemas kini fail Package.json dan buat tag git yang sepadan dengan versi yang baru dikeluarkan
5. Tolak versi baru

Mana -mana CI ok. Dalam artikel ini, kami menggunakan tindakan GitHub kerana saya suka menggunakan ciri-ciri platform yang sedia ada sebelum mencari penyelesaian pihak ketiga.

Terdapat banyak cara untuk memasang pelepasan semantik, tetapi kami akan menggunakan semantik-release-cli kerana ia menyediakan operasi langkah demi langkah. Mari kita jalankan persediaan NPX semantik-release-cli di terminal dan isi wizard interaktif.

Skrip akan melakukan perkara berikut:

• Jalankan NPM AddUser dengan maklumat NPM yang disediakan untuk menjana .NPMRC.
• Buat token akses peribadi GitHub.
• Kemas kini Package.json.

Sebaik sahaja CLI selesai, ia menambah pelepasan semantik ke Package.json, tetapi ia tidak akan memasangnya. Jalankan NPM Pasang untuk memasangnya dan kebergantungan projek lain.

Satu -satunya perkara yang tersisa ialah mengkonfigurasi CI melalui tindakan GitHub. Kita perlu menambah aliran kerja secara manual yang akan menjalankan pelepasan semantik. Mari buat aliran kerja penerbitan dalam .github/aliran kerja/pelepasan.yml.

 <code>name: Release on: push: branches: - main jobs: release: name: Release runs-on: ubuntu-18.04 steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci - name: Release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # If you need an NPM release, you can add the NPM_TOKEN # NPM_TOKEN: ${{ secrets.NPM_TOKEN }} run: npm run release</code>

Steffen Brewersdorff telah melakukan kerja yang baik untuk memperkenalkan CI dengan tindakan GitHub, tetapi mari kita mengkaji secara ringkas apa yang berlaku di sini.

Ini akan menunggu dorongan ke cawangan utama berlaku sebelum saluran paip dijalankan. Anda boleh menukar tetapan ini seperti yang anda suka untuk menjalankan satu, dua, atau semua cawangan.

 <code>on: push: branches: - main</code>

Ia kemudian menggunakan checkout untuk menarik repositori dan memasang nod supaya NPM boleh digunakan untuk memasang kebergantungan projek. Jika ini adalah sesuatu yang anda suka, anda boleh menambah langkah ujian.

 <code>- name: Checkout uses: actions/checkout@v2 - name: Setup Node.js uses: actions/setup-node@v1 with: node-version: 12 - name: Install dependencies run: npm ci # You can add a test step here # - name: Run Tests # run: npm test</code>

Akhirnya, biarkan pelepasan semantik melakukan semua operasi ajaib:

 <code>- name: Release run: npm run release</code>

Tekan perubahan dan lihat tindakan:

Sekarang, setiap kali cawangan tertentu dilakukan (atau digabungkan), operasi dijalankan dan diterbitkan dengan nota pelepasan.

Hantarkan pesta!

Kami telah berjaya mencipta aliran kerja pelepasan semantik CI/CD! Bukankah itu menyakitkan? Persediaannya agak mudah, dan tidak ada kelemahan untuk mempunyai aliran kerja penerbitan semantik. Ia hanya membuat perubahan penjejakan lebih mudah.

Release Semantik Terdapat banyak pemalam yang boleh membolehkan automasi yang lebih maju. Sebagai contoh, terdapat juga bot pelepasan kendur yang boleh diterbitkan ke saluran projek selepas projek itu berjaya digunakan. Tidak perlu pergi ke GitHub untuk mencari kemas kini!

Atas ialah kandungan terperinci Cara mengautomasikan versi dan keluaran projek dengan penggunaan berterusan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!