Panduan: Manajemen Rilis Perangkat Lunak Untuk Tim Kecil

Memformalkan Proses Manajemen Rilis (Jika Ada)

Dalam beberapa konfigurasi tim, terutama yang ditemukan di startup, tidak ada DevOps, atau insinyur infrastruktur, untuk memberikan dukungan saat merilis versi baru produk.

Selain itu, tidak seperti perusahaan birokrasi besar dengan proses formal yang ditentukan, CTO atau Kepala tim Pengembangan Perangkat Lunak dalam sebuah startup sering kali tidak menyadari kerumitan proses manajemen rilis perangkat lunak; beberapa pengembang di perusahaan mungkin mengetahui detail proses yang rumit, tetapi tidak semua orang. Jika pengetahuan ini tidak didokumentasikan secara menyeluruh , saya yakin itu bisa mengakibatkan kebingungan.

Pada artikel ini, saya akan mencoba memberikan beberapa tip tentang bagaimana memformalkan proses rilis, terutama dari sudut pandang pengembang.

Masukkan Daftar Periksa Rilis Perangkat Lunak

Anda mungkin akrab dengan gagasan daftar periksa untuk beberapa operasi, sesuai dengan Manifesto Daftar Periksa , sebuah buku oleh Atul Gawande. Saya percaya proses rilis formal (seperti banyak tugas lain di dunia pengembangan perangkat lunak) memberi pengembang kesempatan untuk mengimplementasikan protokol ini. Daftar periksa proses rilis harus disimpan dalam dokumen bersama, sebaiknya dalam bentuk wiki kolaboratif, atau spreadsheet di Google Drive.

Dengan berbagi dokumen penting ini dengan tim, dan dengan memberikan izin pengeditan, setiap anggota memiliki akses ke proses rilis yang ditentukan secara formal. Ini memungkinkan mereka untuk memahami bagaimana prosesnya bekerja. Selain itu, setelah berdiskusi dengan anggota tim lainnya, ini memberdayakan tim untuk memperbaikinya sesekali. Ini harus membawa transparansi dan memungkinkan seluruh tim untuk memiliki akses real-time ke apa yang terjadi selama rilis, langkah apa yang telah diselesaikan, dan oleh siapa.

Dengan melihat spreadsheet ini, para pemangku kepentingan dapat memutuskan 'GO' vs 'NO GO', berdasarkan hasil dari langkah-langkah tersebut. Misalnya, jika tes stres berjalan salah di lingkungan pengujian, berdasarkan kejadian manajer proyek mungkin memutuskan untuk membatalkan rilis produksi.

Langkah-Langkah yang Disarankan Untuk Digunakan Sebagai Alas Bedak

Di bagian ini, saya akan mengusulkan beberapa langkah yang dapat Anda gunakan untuk membuat daftar periksa Anda sendiri untuk proses rilis Anda. Beberapa langkah ini sama sekali tidak wajib . Setiap aplikasi berbeda dan setiap organisasi bekerja dengan cara yang berbeda, jadi jangan ragu untuk beradaptasi dan membuat perubahan yang lebih sesuai dengan alur kerja Anda.

1. Buat Cabang Rilis

Sepertinya Anda sudah familiar dengan konsep Git Workflow, atau dengan ide cabang rilis, topik yang telah dijelaskan di posting blog sebelumnya.

Idealnya, Anda harus memiliki setidaknya tiga cabang:

• master : ini harus mencerminkan keadaan saat ini dari apa yang ada di lingkungan produksi. Setiap komit baru pada master harus terdiri dari rilis baru saja.
• develop : cabang ini harus berisi fitur-fitur mendatang yang telah selesai (dan diuji). Adalah umum untuk membuat cabang terpisah untuk setiap fitur dan kemudian menggabungkannya untuk dikembangkan ketika fitur sudah siap.
• rilis : cabang rilis adalah kumpulan komit yang siap dikirim ke produksi, ditambah beberapa perbaikan bug minor tambahan yang terkait dengan rilis.

Perhatikan cabang rilis harus dihapus setelah rilis selesai, oleh karena itu cabang ini dibuat dan dihancurkan sepanjang waktu, tidak seperti master atau develop , yang selalu sama.

Untuk membuat cabang rilis baru, dari cabang develop di terminal git Anda, ketik:

$ git checkout -b release/xyz

Lebih mudah menggunakan konvensi penamaan, seperti yang didefinisikan di atas, mengganti xyz dengan nomor versi major.minor.patch sesuai dengan kebutuhan Anda (ini adalah kebijakan yang harus Anda tetapkan dalam tim Anda dan patuhi itu).

Penting juga untuk mengatakan bahwa jika Anda mengkodekan beberapa perbaikan bug ke dalam cabang rilis, Anda tidak boleh lupa untuk menggabungkannya kembali ke develop . Tujuan utama dari cabang rilis adalah untuk memiliki cuplikan pratinjau tentang bagaimana aplikasi harus berperilaku setelah masuk ke produksi.

2. Versi Bump

Langkah selanjutnya adalah menambahkan (memodifikasi atau menambah) nomor versi pada cabang rilis .

Anda harus membuka AndroidManifest.xml / package.json / pom.xml / atau di mana pun versi aplikasi disimpan di proyek Anda (YMMV), perbarui nomor versi, lalu komit perubahan ke cabang rilis saat ini.

Penting untuk memperbarui nomor versi karena dua alasan.

Pertama, Anda dapat melacak dan memetakan fitur yang diperkenalkan di setiap versi, dan kedua, Anda akan mengetahui versi yang mereka gunakan jika mereka perlu melakukan pemecahan masalah atau menghubungi Anda untuk mendapatkan dukungan. Jika Anda sedang membuat aplikasi seluler, nomor versi yang Anda perbarui pada langkah ini biasanya ditampilkan di sisi pengguna, di bagian Tentang atau di Google Play atau Apple App Store . Langkah ini juga merupakan peluang bagus untuk memperbarui yang bergantung pada lingkungan -configuration file (walaupun saya sarankan menyimpannya di repositori terpisah), seperti membuat titik cabang ke database produksi, atau tweak lain yang diperlukan pada proses build.

Terakhir, Anda disarankan untuk mendorong cabang rilis ke asal, sehingga tersedia untuk pengembang Anda yang lain:

$ git push -u origin release/xyz

3a. Gabungkan cabang rilis untuk dikuasai dan diberi tag

Hanya cabang master yang harus digunakan untuk produksi, jadi pada langkah ini, kita perlu menggabungkan cabang rilis menjadi master .

 $ git checkout master $ git merge --no-ff release/xyz $ git push

Bendera --no-ff adalah opsional, namun, penggunaannya disarankan untuk memaksa pembuatan objek komit baru, meskipun penggabungan dapat diselesaikan menggunakan teknik maju cepat.

Selanjutnya, saatnya untuk menandai rilis di cabang master :

$ git tag -a xyz -m 'description of new version, features or fixes included'

Tag berguna karena Anda mempertahankan titik spesifik ini dalam riwayat di repositori git, dan Anda dapat kembali lagi nanti untuk membuat ulang cabang terpisah dari tag tertentu.

3b. Gunakan permintaan tarik untuk menggabungkan cabang rilis

Alternatif lain yang sering digunakan, adalah menggunakan permintaan tarik untuk menggabungkan cabang rilis menjadi master .

Ada banyak keuntungan dari pendekatan ini. Ruang baru dibuat untuk kolaborasi, yang dapat digunakan tim untuk mendiskusikan berbagai masalah terkait rilis. Poin ini adalah saat yang tepat untuk menambahkan gerbang tambahan untuk memasukkan proses peninjauan kode, sambil memiliki lebih banyak bola mata untuk memantau kode yang akan diperkenalkan, dan untuk membahas kemungkinan modifikasi.

Beberapa alat yang memungkinkan Anda untuk menerapkan permintaan tarik ke dalam alur kerja Anda adalah GitHub, Bitbucket, dan GitLab (gabungkan permintaan seperti yang mereka sebut pada yang terakhir). Dengan alat ini, Anda tidak mengetik perintah git secara manual, sebaliknya, Anda menggunakan antarmuka web untuk mengatur cabang sumber ( release ) dan cabang tujuan ( master ), dan kemudian Anda menambahkan satu atau lebih pengulas, yang semuanya akan dapat menulis komentar sebaris tentang perubahan baru ini, menyarankan perbaikan, dan sebagainya.

Setelah semua peninjau menyetujui permintaan tarik, Anda dapat secara otomatis menggabungkan perubahan menjadi master dengan menekan tombol di UI.

4. Menyebarkan Master ke Lingkungan Produksi

Ini adalah praktik yang baik, pada tahap ini, untuk meminta penguji di tim Anda melakukan tes asap (ini dapat ditentukan pada daftar periksa terpisah) sebelum menerapkan aplikasi. Saran yang baik adalah menyebarkan cabang master ke dalam lingkungan pengujian yang terpisah. Penguji kemudian dapat melakukan beberapa tindakan dasar untuk memastikan tidak ada yang salah setelah penggabungan pada versi terbaru. Cara melakukan tes asap berada di luar cakupan artikel ini, tetapi Anda dapat menemukan banyak materi di web tentang hal itu. Hasil uji asap dapat diintegrasikan ke dalam daftar periksa/spreadsheet rilis, yang mendokumentasikan apa pun yang salah.

Pada titik ini, Anda siap untuk menerapkan perubahan dan membuatnya aktif. Silakan dan gunakan cabang master . Langkah ini akan bergantung pada tumpukan infrastruktur yang Anda gunakan. Ini mungkin melibatkan menghubungkan ke instans Amazon EC2 Anda untuk mengunggah aplikasi Anda, atau mendorong ke remote Heroku, atau menghubungkan melalui ssh ke VPS Anda untuk menyalin versi baru, atau proses lainnya.

Setelah aplikasi diunggah, pastikan aplikasi berhasil diterapkan dan berfungsi seperti yang diharapkan.

5. Gabung Kembali Menjadi Kembangkan Dan Hapus Cabang Rilis

Sekarang rilis hampir selesai, Anda ingin menggabungkan cabang rilis menjadi develop , untuk memperbarui nomor versi yang terakhir dan untuk mentransfer semua perbaikan bug yang dibuat ke cabang pengembangan utama:

 $ git checkout develop $ git merge release/xyz

Sekarang saatnya untuk menghapus cabang rilis :

$ git branch -d release/xyz

6. Generasi Changelog

Harus ada file di root proyek Anda bernama CHANGELOG.md (atau yang setara) di mana Anda harus menambahkan entri baru setiap kali ada rilis baru untuk mendokumentasikan semua yang disertakan di dalamnya, seperti perbaikan bug, fitur baru, masalah yang diketahui, dan informasi relevan lainnya dalam bentuk catatan rilis. Ini sangat berguna bagi pengguna dan kontributor untuk melihat perubahan apa yang telah dibuat antara setiap rilis (atau versi) proyek.

Entri changelog termasuk tanggal, nomor versi dan beberapa catatan tentang rilis. Entri harus disimpan dalam urutan kronologis terbalik. Berikut adalah template sederhana yang telah saya gunakan yang dapat Anda sesuaikan dengan proyek Anda:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

Selain itu, langkah ini dapat sepenuhnya otomatis dengan mengkodekan skrip dasar yang melintasi git log dan secara otomatis menghasilkan entri changelog, atau dengan menggunakan alat yang melakukan hal yang sama, seperti:

• Github Changelog Generator, oleh skywinder,
• ReadmeGen oleh fojuth
• github-perubahan, oleh lalitkapoor

Perlu diingat, bahwa tingkat otomatisasi yang Anda dapatkan berbanding lurus dengan ketatnya format pesan komit Anda. Saya percaya itu selalu praktik yang baik untuk menyetujui format khusus untuk pesan komit dengan tim. Dengan mengikuti panduan tentang gaya pesan komit, pesan tersebut akan lebih mudah diuraikan dan oleh karena itu kemungkinan besar Anda akan dapat mengotomatiskan pembuatan log perubahan.

7. Berkomunikasi Dengan Pemangku Kepentingan

Di sinilah Anda biasanya akan melakukan beberapa hal berikut:

• Beri tahu tim melalui alat perpesanan internal (misalnya: Slack) bahwa rilis baru telah selesai. Saya merekomendasikan untuk membuat saluran baru (yaitu: #releases ) dengan tujuan semata-mata untuk mengomunikasikan peristiwa terkait rilis. Sangat mudah untuk menambahkan kait di saluran Slack untuk mengirim pesan setelah tindakan diambil.
• Atau, kirim email ke pemangku kepentingan dengan tautan ke changelog, atau file changelog terlampir.
• Tulis posting blog (jika Anda memiliki blog untuk aplikasi atau produk Anda) atau tweet.

Lebih banyak tindakan dapat diambil tergantung pada sifat organisasi Anda. Yang penting jangan lupa untuk mengomunikasikan bahwa versi baru dari produk Anda telah tersedia.

8. Merawat Pelacak Masalah

Setelah rilis dijalankan, Anda mungkin perlu memperbarui status beberapa tiket Anda untuk melacak perbaikan bug, atau fitur, yang saat ini dalam produksi. Umumnya, ini melibatkan perubahan beberapa tag (untuk proyek kecil saya menggunakan tag rilis-pending , yang saya hapus setelah rilis selesai).

Jika Anda menggunakan pencapaian untuk setiap versi baru, Anda mungkin perlu memperbarui statusnya atau menandainya sebagai selesai. Beberapa pelacak masalah bahkan memungkinkan Anda merencanakan rilis dan menyelaraskannya dengan sprint, melacak apakah ada bug yang memblokir rilis, dan informasi berguna lainnya.

Itu semua tergantung pada bagaimana Anda menggunakan alat tersebut. Saya hanya ingin menunjukkan bahwa tugas memperbarui informasi di pelacak masalah harus disertakan dalam daftar periksa rilis Anda.

Tentang Mengotomatiskan Proses Rilis

Pembaca mungkin telah memperhatikan bahwa, selain dari langkah changelog yang diuraikan di atas, banyak dari langkah-langkah yang disebutkan di atas juga dapat diotomatisasi.

Kemampuan untuk mengotomatiskan beberapa bagian dari proses rilis adalah kemenangan besar dan menghemat banyak waktu. Saya menyarankan untuk membuat skrip, atau mencari tahu cara mengotomatiskan langkah-langkah individual dan kemudian bekerja menuju tujuan pengiriman yang berkelanjutan. Pengiriman berkelanjutan dapat mengurangi risiko, mengurangi biaya, dan mengurangi waktu yang harus dihabiskan pengembang dalam mengelola rilis. Akibatnya, Anda akan dapat merilis lebih sering dan lebih produktif dalam hal jam yang dialokasikan untuk pengembangan.

Cawan suci perusahaan DevOps adalah untuk dapat meluncurkan versi baru dengan menekan tombol (atau menjalankan perintah) yang akan memicu proses rilis secara otomatis, atau bahkan lebih baik, sebuah sistem yang akan merilis versi baru perangkat lunak Anda di a waktu yang ditentukan. Tentu saja, ini sulit dicapai karena Anda juga perlu mengotomatiskan banyak proses pengujian, tetapi bukan tidak mungkin.

Merangkul Praktik Terbaik

Di bagian ini saya akan menjelaskan beberapa praktik yang direkomendasikan yang menurut saya nyaman, baik untuk membuat proses rilis lebih lancar atau untuk mengambil langkah-langkah keamanan jika terjadi kesalahan.

Temukan hari yang paling cocok untuk melakukan pelepasan

Saya biasanya merilis aplikasi yang saya kerjakan pada hari Kamis, antara siang dan tutup bisnis.

Jika Anda bekerja dari Senin hingga Jumat, tidak baik untuk memulai pada hari Jumat. Jika ada yang rusak setelah rilis, Anda tidak akan punya waktu untuk memperbaikinya sampai hari Senin (kecuali jika Anda ingin bekerja selama akhir pekan). Itulah mengapa lebih mudah untuk melakukan rilis pada hari Kamis, karena Anda memiliki hari Jumat untuk memantau versi baru setelah di-deploy, memperbaiki masalah, atau melakukan rollback.

Hal penting lainnya untuk disebutkan jika Anda mengelola aplikasi web, adalah mengetahui zona waktu sebagian besar pengguna Anda berada. Anda harus mengatur waktu rilis selama periode lalu lintas rendah untuk meminimalkan potensi kerusakan jika terjadi kegagalan. Terkadang, ini bisa menjadi rumit ketika basis pengguna Anda tersebar di seluruh dunia, tetapi bagaimanapun juga, Anda harus melakukan riset dan memutuskan waktu terbaik.

Cadangkan Basis Data Anda Sebelum Rilis Baru

Jika Anda tidak memiliki pencadangan berkala dari DB Anda yang dijadwalkan, saya sangat menyarankan Anda menambahkan langkah ke dalam proses rilis Anda untuk melakukan pencadangan sebelum memulai rilis.

Peluncuran Bertahap

Pernah bertanya-tanya mengapa, ketika penerbit mengumumkan bahwa mereka telah meluncurkan fitur baru, butuh berhari-hari, atau bahkan berminggu-minggu, agar fitur itu tersedia di ponsel Anda? Itu karena banyak perusahaan menggunakan peluncuran bertahap.

Facebook telah melakukan ini sejak lama. Ini menguji fitur baru pada lima atau 10 persen penggunanya, secara bertahap meningkatkannya hingga mencapai 100 persen basis pengguna. Selama fase peluncuran bertahap, Anda harus melihat dengan cermat masukan pengguna dan laporan kerusakan. Dengan informasi ini, Anda kemudian dapat menunda rilis, atau memperbaiki kesalahan, sebelum memengaruhi setiap pengguna.

Ada alat yang bagus di Konsol Pengembang Android yang mengimplementasikan peluncuran bertahap untuk aplikasi Android Anda.

Integrasi Berkelanjutan

Integrasi Berkelanjutan adalah praktik yang layak untuk dianut karena berbagai alasan. Pertama, ini memungkinkan Anda untuk mendeteksi kesalahan lebih awal, meningkatkan tingkat rilis yang berhasil. Kedua, ini adalah langkah logis pertama sebelum menerapkan Pengiriman Berkelanjutan dan otomatisasi penuh seperti yang dijelaskan sebelumnya.

Martin Fowler adalah pendukung besar Integrasi Berkelanjutan. Dia menjelaskan sejumlah besar manfaat yang dapat ditambahkan ke proses pelepasan Anda saat menggunakan praktik ini. Ini adalah topik besar dan ada banyak buku dan posting blog tentangnya, dan saya menyebutkannya di sini karena saya yakin ini akan memberi Anda lebih banyak kepercayaan diri dalam operasi Anda. Di antara banyak keuntungan menggunakan CI, Anda akan menemukan: pengurangan risiko, peningkatan visibilitas untuk mengetahui apa yang berhasil dan apa yang tidak, deteksi bug lebih awal, peningkatan frekuensi penerapan, dan banyak lagi.

Titik awal untuk mengimplementasikan CI adalah menyiapkan “server integrasi berkelanjutan;” beberapa alat yang bagus untuk dicoba adalah: CruiseControl, Bamboo, Jenkins dan Travis.

Keluar: Semuanya Akan Berhasil

Secara agresif, kita semua mempertahankan peran yang kita mainkan Sayangnya, saatnya tiba untuk mengirim Anda ke jalan Anda Kami telah melihat semuanya, api unggun kepercayaan, banjir rasa sakit Itu tidak terlalu penting, jangan khawatir, itu akan semua bekerja

Keluar, The Killers

Sebagai penutup, saya akan mengatakan bahwa sangat penting untuk memiliki proses rilis yang terdefinisi dengan baik untuk aplikasi Anda, terlepas dari kompleksitasnya, basis pengguna, atau seberapa kecil organisasi Anda.

Jika tidak, saya sarankan Anda mulai memikirkan beberapa langkah dasar, menggunakan panduan ini dan yang lain seperti itu, dan bertukar pikiran dengan tim Anda untuk menghasilkan draf pertama. Cobalah pada rilis berikutnya, lalu ulangi. Pada akhirnya, Anda akan membangun proses rilis Anda sendiri.

Setelah itu, mulailah berpikir tentang bagaimana mengotomatisasi bagian-bagian dari proses . Pikirkan tentang area yang dapat ditingkatkan. Jelajahi cara untuk mengurangi waktu rilis dengan memasukkan pengoptimalan kecil. Otomatisasi harus menjadi tujuan akhir Anda; namun, jangan rencanakan itu sejak awal, atau Anda akan gagal dengan mencoba lompatan besar tersebut. Seperti halnya setiap proses, lebih baik untuk meningkatkannya secara bertahap.

Apakah Anda memiliki trik atau pedoman lain yang Anda gunakan untuk meluncurkan versi baru aplikasi Anda? Jika demikian, beri tahu saya. Saya tidak berasal dari dunia DevOps, saya hanya seorang pengembang yang kebetulan cukup terorganisir dan terstruktur, tetapi dibandingkan dengan banyak veteran, saya masih pemula dalam hal ini, jadi jangan ragu untuk berkomentar atau hubungi saya jika Anda memiliki sesuatu untuk ditambahkan.