Belum lama ini, di salah satu proyek perusahaan kami, diputuskan untuk akhirnya meninggalkan penggunaan Subversion untuk menyimpan dan membuat kode versi yang mendukung Git.
Tujuan utama transisi adalah sebagai berikut:
- Meningkatkan transparansi proses pembangunan.
- Penerapan prosedur peninjauan kode wajib sebelum memperbarui pembaruan ke lingkungan pengujian.
- Terapkan integrasi berkesinambungan untuk membangun pembaruan setelah peninjauan kode dan memasangnya di lingkungan pengujian.
Prasyarat untuk mencapai tujuan ini adalah penggunaan GitLab (server Git ini sudah digunakan oleh pelanggan dan sudah ada kode di bagian depan solusi) dan Jira (juga sudah digunakan oleh pelanggan).
Diusulkan untuk menggunakan Git Flow sebagai model pengembangan target, menambahkan kode ulasan untuk itu. Model pengembangan de facto ini telah menjadi standar dalam pengembangan perangkat lunak open source dan digunakan oleh sebagian besar raksasa industri. Itulah sebabnya dukungannya dibangun ke dalam banyak alat populer untuk bekerja dengan Git. Sejumlah besar bahan telah ditulis pada topik penggunaannya, saya akan mengutip yang paling sukses dari mereka untuk pengenalan awal: satu dan dua .
Dengan sendirinya, model ini hanya menawarkan prinsip-prinsip umum pemeliharaan kode, meninggalkan proses yang menyertai penulisan. Oleh karena itu, implementasi segalanya, termasuk kode ulasan, tergantung pada server Git tertentu. Dalam hal ini, GitHub paling nyaman: ia awalnya dibangun sebagai platform untuk kolaborasi sejumlah besar pengembang independen dan memungkinkan Anda untuk membatasi hak untuk mengirim komit (Dorong) dalam repositori dengan kemampuan untuk membuat permintaan pengiriman kode. Selain itu, GitLab menawarkan alur kerjanya sendiri untuk mempertahankan kode yang disebut GitLab Flow, yang dirancang untuk menggunakan GitLab CI. Oleh karena itu, di GitLab, fungsionalitas untuk membuat permintaan untuk mengirim kode tidak diimplementasikan dan diusulkan untuk menggunakan permintaan gabungan cabang untuk meninjau kode perubahan. Untuk membangun dan menginstal artefak pada proyek, Jenkins sudah digunakan, yang memungkinkan Anda untuk secara fleksibel membuat dan mengkonfigurasi tugas-tugas perakitan dan penyebaran, dan diputuskan untuk tidak beralih ke GitLab CI, sekaligus menolak gagasan untuk menggunakan GitLab Flow.
Saya juga mencatat bahwa proyek ini telah mengkonfigurasi integrasi di Jira dan Git. Di Jira, di plugin Git, repositori yang dibuat untuk menyimpan kode sumber ditambahkan untuk pelacakan, dan di GitLab, repositori ini dikonfigurasikan untuk berintegrasi dengan Jira di bagian "Integrasi" repositori.
Untuk mengatasi masalah ini, alur kerja untuk bekerja dengan kode dikembangkan yang mirip dalam struktur dengan Git Flow, tetapi memungkinkan Anda untuk meninjau kode setiap kali Anda membuat perubahan ke cabang proses utama (mengembangkan, melepaskan-n dan master) menggunakan GitLab. Selanjutnya, proses yang dihasilkan akan dijelaskan, serta tahapan integrasi berkelanjutan dan pengiriman perangkat lunak ke string yang berdekatan dengannya. Dalam tanda kurung adalah perintah yang sesuai untuk dieksekusi.
Repositori yang dibuat untuk menyimpan kode sumber diunggah ke repositori lokal (git clone) dan Git Flow (git flow init) diinisialisasi di dalamnya - selain cabang master (untuk membuat tag untuk menyimpan rilis yang stabil), cabang pengembangan dibuat (cabang pengembangan utama, di yang mengintegrasikan cabang fungsi, rilis dan perbaikan), masker untuk cabang fungsi, rilis dan perbaikan diatur, dan transisi ke cabang pengembangan juga dibuat.
Selanjutnya, cabang kode sumber saat ini dari Subversion ditransfer ke copy pekerjaan, kode tersebut dikomit (git add -A + git commit -m “Commit message”) ke cabang pengembangan repositori lokal dan unggahannya ke repositori jarak jauh (asal git push dikembangkan). Setelah itu, Anda dapat mulai mengembangkan fungsionalitas baru menggunakan Git untuk membuat versi kode.
Selama pengembangan, versi terkini dari cabang pengembangan diunduh dan cabang dibuat darinya untuk pengembangan fungsi baru (fitur git flow memulai MYFEATURE) sesuai dengan kode tugas Jira di mana pengembangan sedang dilakukan.
Transisi ke cabang yang dibuat (git checkout MYFEATURE) secara otomatis dilakukan, fungsionalitas yang direncanakan dikembangkan dan perubahan dilakukan ke cabang MYFEATURE lokal (git commit -m “Pesan komit”). Perhatikan bahwa untuk integrasi Git dan Jira yang benar, kode komit di Jira yang berlaku untuk perbaikan ini harus ditunjukkan dalam pesan komit. Kemudian komit-komit ini akan ditampilkan dalam tugas-tugas yang berkaitan dengannya, dan juga di bagian “Git commit” proyek, dengan bantuan yang Anda dapat dengan jelas menentukan apa yang termasuk dalam rilis tertentu.
Ketika fungsionalitas tugas yang dipilih dikembangkan dan siap untuk diserahkan ke lingkungan pengujian, komit yang dibuat diunggah ke cabang jarak jauh dengan nama yang sama (git push -u origin MYFEATURE) dan permintaan untuk menggabungkan cabang yang diunduh dengan cabang pengembangan dibuat untuk pimpinan tim atau tugas aktingnya.
Untuk meminta penggabungan, pengembang menyelesaikan konflik penggabungan (jika ada) dan pemimpin tim pengembangan (atau akting) menghasilkan tinjauan kode, di mana dimungkinkan untuk membuat komit tambahan (git commit -m "Pesan Komit") dengan koreksi pada komentar yang diterima selama tinjauan kode, dalam cabang dengan fungsionalitas baru dan mengirimkannya ke repositori pusat (git push -u origin MYFEATURE). Setelah berhasil menyelesaikan tinjauan, pemimpin tim (atau akting) mengonfirmasi penggabungan cabang. Di sini tidak berlebihan untuk mengatur bendera untuk menghapus cabang setelah merger - jika tidak, jumlah cabang dapat dengan cepat tumbuh menjadi skala tidak senonoh.
Untuk memastikan integrasi berkelanjutan dalam repositori GitLab, Web Hook dikonfigurasikan di bagian "Integrasi", yang memanggil tugas Jenkins untuk membangun dan menginstal fungsionalitas baru pada lingkungan pengujian. Jenkins, menggunakan plug-in untuk bekerja dengan Git, mengunduh kode sumber, mendapatkan nama tugas darinya dan menggunakan Jira API untuk meminta daftar komponen yang telah diubah dan perlu dirakit, memulai proses pembuatan, menjalankan tes Unit, dan memuat artefak yang dibuat jika mereka berhasil lulus di Sonatype Nexus dan memasangnya di lingkungan pengujian. Jika pada salah satu tahap terjadi kegagalan atau Unit test gagal, maka dengan bantuan Telegram plug-in tim pengembangan diberitahu tentang hasil pembangunan. Jika instalasi berhasil, maka tim QA diberitahu bahwa tugas siap untuk pengujian.
Jika cacat muncul, versi saat ini dari cabang pengembangan diunduh dan dari komit gabungan cabang MYFEATURE dengan cabang pengembangan, cabang hotfix-MYFEATURE dibuat (git checkout [BASECOMMIT] -b hotfix-MYFEATURE).
Saat membuat, checkout dilakukan secara otomatis ke cabang yang dibuat, koreksi dilakukan dan perubahan dilakukan ke hotfix cabang lokal-MYFEATURE (git commit hotfix-MYFEATURE -m "pesan komit"). Ketika koreksi selesai dan siap untuk diserahkan ke lingkungan pengujian, mereka didorong ke cabang jauh dengan nama yang sama (git push-hotfix asal-MYFEATURE) dan permintaan gabungan dibuat dengan cabang berkembang.
Untuk meminta penggabungan, pengembang menyelesaikan konflik penggabungan (jika ada) dan melakukan peninjauan kode, di mana dimungkinkan untuk membuat komit tambahan dengan koreksi pada komentar yang diterima. Setelah peninjauan berhasil diselesaikan, cabang bergabung. Segera setelah tambalan ditransfer ke cabang pengembangan, Web Hook juga berfungsi untuk memanggil tugas di Jenkins untuk membangun, menjalankan pengujian Unit, memuat artefak yang dibuat ke dalam Sonatype Nexus dan menginstal tambalan pada lingkungan pengujian. Mekanisme pemberitahuan serupa berfungsi untuk koreksi.
Jika semua cacat diperbaiki, versi saat ini dari cabang pengembangan diunduh dan dari komit gabungan dari cabang hotfix-MYFEATURE dengan cabang berkembang, cabang rilis-mn dibuat (mulai rilis git flow mulai RELEASENAME [BASECOMMIT]).
Membuat cabang rilis juga menginisialisasi peluncuran Web Hook untuk memanggil tugas di Jenkins, yang mengunduh kode sumber dari Git, memperoleh nama cabang rilis dari itu dan, menggunakan Jira API, menanyakan daftar komponen yang diubah sebagai bagian dari tugas rilis, mengunduh versi saat ini dari Sonatype Nexus dan set mereka ke lingkungan pengujian regresi. Setelah pemasangan rilis pada lingkungan pengujian regresi, skrip dijalankan untuk mempersiapkan lingkungan untuk pengujian (restart aplikasi, membersihkan database, dll.) Dan tes mandiri regresi dijalankan untuk memeriksa operasi fungsionalitas sistem utama, yang menghasilkan laporan menggunakan plugin Allure Reports untuk Jenkins. Setelah instalasi, tim QA diberitahu di Telegram tentang hasil lari autotest dan kesiapan rilis untuk pengujian regresi manual.
Jika cacat muncul selama pengujian regresi, versi saat ini dari cabang rilis-mn diunduh dan, dari komit terakhir, cabang hotfix / BUGNAME dibuat dengan nama cacat di Jira (git checkout -b hotfix / BUGNAME [BASECOMMIT]).
Sebuah checkout secara otomatis dilakukan ke cabang yang dibuat, koreksi yang diperlukan dibuat dan perubahan dilakukan ke hotfix cabang lokal / BUGNAME (git commit hotfix / BUGNAME -m "Pesan komit"). Ketika koreksi selesai dan siap untuk diserahkan ke lingkungan pengujian regresi, mereka didorong ke cabang jauh dengan nama yang sama (git push-hotfix asal / BUGNAME) dan permintaan gabungan dibuat dengan cabang rilis-mn
Untuk meminta penggabungan, pengembang menyelesaikan konflik penggabungan (jika ada) dan melakukan peninjauan kode, di mana dimungkinkan untuk membuat komitmen tambahan dengan koreksi pada komentar yang diterima selama peninjauan kode. Komit-komit ini juga dibuat untuk hotfix cabang lokal / BUGNAME (git commit hotfix / BUGNAME -m “Commit message”) dan mereka didorong ke cabang jauh dengan nama yang sama (git push-hotfix asal / BUGNAME). Setelah peninjauan berhasil diselesaikan, cabang bergabung. Penggabungan menginisialisasi peluncuran Web Hook untuk menjalankan tugas di Jenkins, mirip dengan yang sebelumnya, tetapi berbeda karena mengunduh kode dari Git, mendapatkan nama cacat dari itu, menggunakan Jira API untuk meminta daftar komponen yang diubah sebagai bagian dari perbaikan, mengumpulkan komponen-komponen ini, mengunduh ke Sonatype Nexus dan menginstalnya pada lingkungan pengujian regresi. Lebih lanjut, dengan analogi, lingkungan dipersiapkan untuk autotest, autotest regresi dijalankan, dan hasilnya diberitahukan.
Ketika semua cacat diperbaiki, rilis dipasang pada lingkungan yang produktif. Untuk melakukan ini, gabungkan cabang rilis-mn dengan mengembangkan dan menguasai cabang, dan juga membuat tag rilis.
Ketika dibuat, ia memulai peluncuran Web Hook untuk memanggil tugas di Jenkins, yang mengunduh kode sumber dari Git, memperoleh nomor rilis darinya, dan menggunakan Jira API, meminta daftar tugas yang termasuk dalam rilis dan komponen yang diubah sebagai bagian dari tugas ini. yang memompa keluar versi artefak saat ini dari Sonatype Nexus dan memasangnya di lingkungan yang produktif.
Dengan perbaikan terbaru untuk penjualan, diputuskan untuk menggunakan proses yang mirip dengan rilis - jika tidak, tahap pengujian dari perubahan yang dilakukan akan hilang.
Ketika menerapkan proses, pelatihan juga dilakukan untuk karyawan yang tidak memiliki pengalaman bekerja dengan Git dan GitLab, yang mana program pelatihan yang sesuai dikembangkan. Dengan itu, Anda sendiri akan dapat melakukan pelatihan tentang penggunaan Source Tree dan Intellij IDEA untuk bekerja dengan Git, serta GitLab untuk melakukan tinjauan kode. Dalam posting berikutnya saya akan memberikannya, ditambah dengan ilustrasi.