Tingkatkan rilis Anda

Henry Ford pernah berkata: "Mobil terbaik adalah mobil baru." Jadi kami di grup perusahaan Tinkoff memikirkan rilis perangkat lunak. Kelambanan dalam proses menghadirkan fitur dan perbaikan mendesak cepat atau lambat mengarah ke hutang teknis yang besar kepada pelanggan dan paling sering berakhir dengan stagnasi proyek secara keseluruhan.

Menjamin indikator waktu ke pasar yang tinggi dengan tetap menjaga kualitas bukanlah tugas yang mudah. Dari sudut pandang saya, Anda tidak dapat langsung membangun rel yang memungkinkan untuk melakukan perubahan secara cepat dan mudah berbulan-bulan setelah dimulainya. Pertumbuhan proyek biasanya disertai dengan peningkatan jumlah orang yang mengerjakannya, yang berarti itu menciptakan sumber kekacauan potensial dalam rilis Anda.

Pengalaman kami hampir tidak layak dipertimbangkan sebagai instruksi untuk sukses, tetapi sejumlah ide tampaknya cukup menarik untuk saya bagikan kepada Anda. Mari kita mulai.

Titik awal sejarah kami secara teknis adalah sebagai berikut. Sistem ini terdiri dari beberapa layanan, basis kode yang digeledah oleh sekitar 30 orang - beberapa tim yang dibagi berdasarkan area bisnis, misalnya, melayani individu dan badan hukum. Saya akan mencoba mengabaikan detail teknis dan arsitektur proyek untuk fokus pada proses rilis itu sendiri.

Kami mengerjakan Gitflow , jadi artikel ini akan menarik bagi mereka yang memilih metode pengiriman khusus ini.

Masalahnya

Masalah pertama yang kami temui terkait dengan otomatisasi proses yang tidak memadai . Implementasi semua aktivitas rilis di tim kami terkait dengan peran manajer rilis (RM).

Inilah beberapa di antaranya:

1. Meninggalkan cabang rilis dan membuat tag.
2. Menggabungkan dengan menguasai dan mengembangkan cabang.
3. Bangun dan gunakan artefak yang termasuk dalam rilis.
4. Komunikasi dengan spesialis yang terlibat dalam proses - misalnya, dengan QA atau administrator.

Tugas-tugas rutin ini membutuhkan lebih banyak sumber daya saat proyek berkembang (dalam kasus kami, peningkatan jumlah layanan), sehingga langkah pertama adalah mengotomatisasi semua yang dapat diotomatisasi. Kami mengintegrasikan dengan alat CI / CD untuk mengalihkan dan menggabungkan cabang rilis, meluncurkan uji coba bangunan dan menggunakan artefak menggunakan tombol; dengan alat pelacak tugas dan messenger perusahaan untuk pemberitahuan tepat waktu dari peserta yang bertanggung jawab untuk langkah selanjutnya - misalnya, mengubah status tugas dan mengonfigurasi kait untuk mengirim pemberitahuan.

Manajer rilis masih harus menyelesaikan secara manual potensi konflik yang timbul dari penggabungan cabang, tetapi rilis yang cepat dan sering harus mengurangi jumlahnya menjadi nol.

Masalah selanjutnya adalah pengujian .

Salah satu kriteria build untuk kami adalah keberhasilan pelaksanaan tes. Biasanya membagi tes menjadi setidaknya dua jenis: unit dan integrasi.

Tes unit memungkinkan Anda untuk memeriksa kebenaran masing-masing modul dari kode sumber program, yang dalam praktiknya paling sering datang untuk memeriksa satu atau lebih metode yang memiliki koneksi logis yang jelas.

Tes integrasi biasanya memeriksa operabilitas kaskade keseluruhan modul tersebut, yaitu, fungsi seluruh fitur di sisi klien. Misalnya, jika rest-interface diimplementasikan dalam sebuah tugas, maka kami akan memeriksa operabilitas otorisasi, deserialisasi permintaan itu sendiri, validitas bidang yang ditransmisikan, integrasi dengan layanan dan database lain, serta logika bisnis itu sendiri. Pada pandangan pertama, mungkin tampak bahwa tes semacam itu sangat mandiri dan mampu mencakup semua area masalah potensial. Tidak perlu memahami bagaimana masing-masing bata bekerja, dan antarmuka yang dipanggil merangkum semua logika untuk mendapatkan jawaban sederhana pada output: apakah itu berfungsi atau tidak.

Bahkan, mereka menciptakan sejumlah masalah yang ditangguhkan, berikut adalah beberapa di antaranya:

1. Partisipasi dari sejumlah besar komponen yang diuji secara proporsional mempengaruhi waktu perakitan dan pelaksanaan pengujian tersebut.
2. Enkapsulasi tes logika sering mengarah pada fakta bahwa sulit untuk menjamin kebenaran hasil tes. Seringkali kita menyesuaikan tes untuk hasilnya, dan bahkan lebih sering hasilnya sesuai dengan harapan karena efek samping acak.
3. Relevansi data uji hilang.
4. Integrasi dengan sistem pihak ketiga, terutama pada lingkungan pengujian, sering jatuh. Ini meniadakan waktu yang dihabiskan untuk berlari, karena tidak selalu jelas: ini adalah penurunan atau kerusakan sementara yang disebabkan oleh perubahan kami.

Untuk sebagian besar masalah sudah ada solusi. Namun, seperti biasa, solusi tidak datang tanpa batasan tambahan atau masalah baru.

Memilih tes yang tepat untuk Anda dan menerapkannya dengan benar adalah tugas yang sangat sulit. Selain itu, penting untuk menyeimbangkan antara kualitas cakupan dan membangun kecepatan untuk mengoptimalkan rilis Anda.

Dalam kasus kami, kami memilih hibrida. Kami terus meningkatkan semua komponen yang diperlukan untuk pengujian fitur lengkap, secara bersamaan mencuci semua kemungkinan integrasi. Untuk menyimpan kontrak API, kami menggunakan Pakta , dan untuk memeriksa integrasi dengan database - Testcontainers .

Pendekatan semacam itu untuk menulis tes sebagai hasilnya menghasilkan solusi untuk masalah ketiga - waktu yang lama untuk pengujian tugas secara manual . Stabilitas tes hybrid telah mengarah pada ide menarik insinyur QA pada tahap menentukan tugas untuk menyusun kasus uji - ini akan memungkinkan mereka dilewati pada tahap pengujian manual. Integrasi dengan produk yang bermanfaat seperti TestRail dan Allure telah menjadi semacam jembatan antara pengembang dan penguji. Sebuah kontrak dibuat, pelaksanaannya selangkah demi selangkah tercermin dalam laporan yang dihasilkan selama perakitan uji.

Tetap menghubungkan laporan ke alat pelacakan tugas Anda untuk pelacakan tugas transparan. Cerita yang jelas juga akan mengurangi waktu yang dibutuhkan untuk menyusun dan mengimplementasikan tes untuk tugas terkait di masa depan.

Dengan cara ini, insinyur QA menghemat waktu yang cukup untuk fokus pada pengujian kasus luar biasa dan berintegrasi dengan sistem lain.

Masalah terakhir terkait dengan ini. Untuk pengujian manual, semua tugas bergabung dari cabang fitur dalam mengembangkan dan meluncurkan penyebaran ke bangku tes.

Pertama, dengan pendekatan ini, Anda tidak dapat berbicara tentang pengujian murni fitur, karena secara paralel perubahan terkait pengembang lain mungkin jatuh ke dalam pengembangan.

Kedua, ketika melepaskan cabang rilis, mungkin ternyata QA tidak punya waktu untuk menguji beberapa tugas. Ada pilihan: memutar kembali perubahan yang dipengaruhi oleh tugas-tugas ini, atau memperlambat rilis sampai akhir pengujian.

Anda harus membuat pilihan seperti itu setiap saat, kecuali jika Anda mengisolasi lingkungan pengujian Anda . Penting bahwa tidak ada perubahan dalam komponen yang diuji selain yang dilakukan oleh tugas. Dalam kasus kami, kami harus dapat mengambil satu atau beberapa layanan yang cabangnya telah mengalami perubahan, dan mengelola perutean di dalam kluster, mengarahkan ke instance ini hanya permintaan yang kami butuhkan dari QA. Tugas ini rumit jika mekanisme penyeimbangan sudah digunakan pada gugus, yang juga harus diperhitungkan.

Setelah menyadari peluang ini, kami mulai melakukan pengujian manual secara langsung pada cabang fitur yang terpisah: menyebarkan layanan yang diperlukan selama pengujian, mengintegrasikan ke dalam lingkungan keseluruhan secara terpisah. Dengan menggabungkan hanya tugas-tugas yang sudah jadi ke cabang pengembangan dan menyingkirkan kunci, kami sendiri mulai menentukan perubahan mana yang harus dimasukkan dalam rilis dan mana yang tidak.

Perlu dicatat bahwa solusi seperti itu tidak mungkin menjadi peluru perak bagi tim-tim yang melakukan perubahan pada file yang hampir sama. Dalam hal ini, penyimpanan fitur berbanding terbalik dengan jumlah konflik yang muncul selama merger. Dalam praktiknya, dengan rilis yang cukup sering, ini sangat jarang terjadi dalam tim dengan lima puluh pengembang.

Alih-alih output

Meringkas, kami dapat mengidentifikasi pendekatan utama yang dapat membantu mempercepat rilis:

1. Otomatisasi operasi rutin.
2. Transparansi proses untuk semua yang terlibat.
3. Keseimbangan yang diperlukan antara kecepatan dan kualitas dalam menulis tes otomatis.
4. Mengurangi waktu untuk pengujian manual.
5. Isolasi lingkungan untuk pengujian.

Penting untuk dipahami bahwa dalam memilih berbagai pendekatan, prinsip dan strategi, selalu layak dimulai dari konteks masalah Anda. Ada banyak cara yang sama andal dan lebih canggih untuk mempercepat pengiriman perangkat lunak Anda kepada klien. Upaya untuk merespons kesulitan yang baru muncul telah menghasilkan kesimpulan yang dijelaskan di atas. Bagi kami, mereka adalah langkah pertama menuju pendekatan yang lebih berani untuk merilis rilis .