Jika perusahaan Anda hanya menerapkan alat DevOps atau CI/CD, mungkin berguna bagi Anda untuk mengetahui kesalahan yang paling umum sehingga Anda tidak mengulanginya dan menginjak penggaruk orang lain.
Tim menerjemahkan artikel tersebut .
Keengganan untuk mengubah budaya dan proses
Melihat diagram siklus , jelas bahwa dalam praktik DevOps, pengujian adalah pekerjaan berkelanjutan, bagian mendasar dari setiap penerapan individu.
Diagram Siklus Tanpa Akhir DevOps
Pengujian dan jaminan kualitas selama pengembangan dan pengiriman merupakan bagian penting dari semua yang dilakukan developer. Ini membutuhkan perubahan pola pikir untuk memasukkan pengujian dalam setiap tugas.
Pengujian menjadi bagian dari pekerjaan sehari-hari setiap anggota tim. Transisi ke pengujian berkelanjutan tidaklah mudah, Anda harus siap untuk ini.
Kurangnya umpan balik
Efektivitas DevOps bergantung pada umpan balik yang konstan. Peningkatan berkelanjutan tidak mungkin dilakukan jika tidak ada ruang untuk kolaborasi dan komunikasi.
Perusahaan yang tidak menyelenggarakan pertemuan retrospektif sulit menerapkan budaya umpan balik berkelanjutan di CI/CD. Pertemuan retrospektif diadakan di akhir setiap iterasi, di mana anggota kelompok mendiskusikan apa yang berjalan dengan baik dan apa yang salah. Rapat retrospektif adalah dasar dari Scrum/Agile, tetapi juga penting untuk DevOps.
Hal ini karena pertemuan retrospektif menanamkan kebiasaan saling bertukar pendapat dan pendapat. Salah satu momen terpenting di awal adalah pengorganisasian pertemuan retro berulang sehingga menjadi dapat dimengerti dan akrab bagi seluruh tim.
Dalam hal kualitas perangkat lunak, semua anggota tim bertanggung jawab untuk memeliharanya. Misalnya, pengembang dapat menulis pengujian unit serta kode dengan mempertimbangkan kemampuan pengujian, membantu mengurangi risiko sejak awal.
Salah satu cara mudah untuk mencerminkan persepsi pengujian yang berubah adalah dengan memanggil penguji bukan QA tetapi penguji perangkat lunak atau insinyur kualitas. Perubahan ini mungkin tampak terlalu sederhana atau bahkan bodoh. Tetapi menyebut seseorang sebagai "spesialis jaminan kualitas perangkat lunak" memberikan gagasan yang salah tentang siapa yang bertanggung jawab atas kualitas produk. Dalam praktik Agile, CI/CD, dan DevOps, setiap orang bertanggung jawab atas kualitas perangkat lunak.
Poin penting lainnya adalah memahami apa arti kualitas bagi seluruh tim dan setiap anggotanya, organisasi, pemangku kepentingan.
Kesalahpahaman penyelesaian tahap
Jika kualitas adalah proses yang berkelanjutan dan dibagi, diperlukan pemahaman bersama tentang penyelesaian suatu tahap. Bagaimana memahami bahwa panggung sudah berakhir? Apa yang terjadi jika sebuah pencapaian ditandai sebagai selesai di papan Trello atau papan kanban lainnya?
Menentukan tonggak pencapaian (DoD) adalah alat yang ampuh dalam konteks CD DevOps/CI. Ini membantu untuk lebih memahami standar kualitas dari apa dan bagaimana tim membangun.
Tim pengembangan harus memutuskan apa artinya "Selesai". Mereka perlu duduk bersama dan membuat daftar ciri-ciri yang harus dipenuhi pada setiap tahapan agar bisa dianggap lengkap.
DoD membuat proses lebih transparan dan memfasilitasi implementasi CI/CD, jika jelas bagi semua anggota tim dan disepakati bersama.
Kurangnya tujuan yang realistis dan jelas
Ini adalah salah satu tip yang paling sering dikutip, tetapi perlu diulangi. Agar upaya serius apa pun berhasil, termasuk mengimplementasikan CI/CD atau DevOps, Anda perlu menetapkan tujuan yang realistis dan mengukur kinerja terhadapnya. Apa yang ingin Anda capai dengan CI/CD? Apakah ini memungkinkan rilis yang lebih cepat dengan kualitas yang lebih baik?
Tujuan apa pun yang ditetapkan tidak hanya harus transparan dan realistis, tetapi juga konsisten dengan aktivitas perusahaan saat ini. Misalnya, seberapa sering pelanggan Anda membutuhkan tambalan atau versi baru? Tidak perlu membebani proses dan merilis lebih cepat jika tidak ada manfaat tambahan bagi pengguna.
Selain itu, Anda tidak selalu perlu mengimplementasikan CD dan CI. Misalnya, perusahaan dengan regulasi ketat seperti bank dan klinik kesehatan hanya boleh bekerja sama dengan CI.
CI adalah titik awal yang baik untuk perusahaan mana pun yang menerapkan DevOps. Ketika diterapkan di perusahaan, pendekatan pengiriman perangkat lunak berubah secara signifikan. Setelah CI dikuasai, Anda dapat memikirkan untuk meningkatkan keseluruhan proses, meningkatkan kecepatan peluncuran, dan perubahan lainnya.
Bagi banyak organisasi, satu CI sudah cukup, dan CD hanya boleh diimplementasikan jika menambah nilai.
Kurangnya dasbor dan metrik yang relevan
Setelah Anda menetapkan sasaran, tim pengembangan dapat membuat dasbor untuk mengukur KPI. Sebelum pengembangannya, ada baiknya mengevaluasi parameter yang akan dipantau.
Laporan dan aplikasi yang berbeda berguna untuk anggota tim yang berbeda. Scrum master lebih mementingkan status dan jangkauan. Sementara manajemen senior mungkin tertarik pada tingkat kelelahan para spesialis.
Beberapa tim juga menggunakan dasbor dengan indikator merah, kuning dan hijau untuk menilai status CI / CD, untuk memahami apakah mereka melakukan semuanya dengan benar atau telah terjadi kesalahan. Merah berarti Anda perlu memperhatikan apa yang sedang terjadi.
Namun, jika dashboard tidak terstandarisasi, maka dapat menyesatkan. Analisis data apa yang dibutuhkan setiap orang dan kemudian buat deskripsi standar tentang artinya. Cari tahu apa yang lebih masuk akal bagi pemangku kepentingan Anda: grafik, teks, atau angka.
Kurangnya tes manual
Otomatisasi pengujian meletakkan dasar untuk pipeline CI/CD yang baik. Tetapi pengujian otomatis di semua tahap tidak berarti Anda tidak boleh melakukan pengujian manual.
Untuk membangun pipeline CI/CD yang efisien, pengujian manual juga diperlukan. Akan selalu ada beberapa aspek pengujian yang memerlukan analisis manusia.
Perlu dipertimbangkan untuk mengintegrasikan upaya pengujian manual ke dalam pipeline. Setelah pengujian manual beberapa kasus uji selesai, Anda dapat melanjutkan ke fase penerapan.
Jangan mencoba untuk meningkatkan tes
Pipeline CI/CD yang efektif memerlukan akses ke alat yang tepat, apakah itu manajemen pengujian atau integrasi dan pemantauan berkelanjutan.
Menciptakan budaya yang kuat dan berorientasi pada kualitas bertujuan untuk , pantau pengalaman pelanggan setelah penerapan, dan lacak peningkatan.
Berikut adalah beberapa tips praktis yang dapat Anda terapkan dengan mudah:
- Pastikan pengujian mudah untuk ditulis dan cukup fleksibel agar tidak rusak saat kode direfaktor ulang.
- Tim pengembangan harus disertakan dalam proses pengujian - lihat daftar masalah dan permintaan pengguna yang penting untuk diuji selama pipeline CI.
- Anda mungkin tidak memiliki cakupan pengujian penuh, tetapi selalu pastikan alur yang penting untuk UX dan pengalaman pelanggan telah diuji.
Poin terakhir namun tidak kalah pentingnya
Transisi ke CI/CD biasanya dimulai dari bawah ke atas, namun pada akhirnya merupakan transformasi yang membutuhkan partisipasi manajemen, waktu dan sumber daya dari perusahaan. Bagaimanapun, CI / CD adalah seperangkat keterampilan, proses, alat, dan restrukturisasi budaya, perubahan semacam itu hanya dapat diterapkan secara sistematis.
Apa lagi yang harus dibaca tentang topik tersebut:
- .
- .
- .
Sumber: www.habr.com