Bayangkan situasi yang fantastis - direktur perusahaan memutuskan untuk menerapkan DevOps. Dirinya sendiri, tanpa tekanan dari teknisi. Tanpa contoh pesaing yang meyakinkan. Manajemen itu sendiri mengakui bahwa tidak mungkin untuk meningkatkan kualitas produk, prediktabilitas, transparansi dan pengulangan proses bisnis dalam pengembangan dan implementasi perangkat lunak tanpa alat DevOps.
Disajikan? Apakah itu berhasil? Anda telah berhasil lulus ujian untuk imajinasi terkaya!
Sebenarnya, tentu saja tidak demikian. Paling sering, manajemen tidak sesuai dengan hal-hal IT kami. Karena itu, Anda harus meyakinkan. Tapi bagaimana caranya?
Ketika sebuah argumen diberikan untuk meningkatkan budaya komunikasi antara programmer dan administrator sistem, mudah untuk menghadapi kontra-argumen: apakah Anda tidak beradab sekarang, atau apa? Atau mereka bahkan dapat mengingatkan Anda tentang biaya yang telah dikeluarkan perusahaan satu atau dua tahun yang lalu ketika Anda pindah bersama ke Agile. Apakah ada fitur dalam TI setiap tahun yang dapat memajukan proses secara revolusioner?
Sedangkan untuk meningkatkan kualitas produk, Anda juga bisa gagap. Tapi hati-hati. Karena tugas pemrograman tanpa kesalahan belum dibatalkan. Ya, tidak ada bug dengan cara apa pun, tapi itu sebabnya perusahaan memiliki "seluruh departemen penguji", kan?
Prediktabilitas proses umumnya merupakan faktor subyektif, yang cukup sulit untuk dibenarkan dan menghindari lelucon tentang Wang dan Nostradamus.
Selain itu, jika kita berbicara tentang perusahaan yang khas, maka di perusahaan seperti itu, kemungkinan besar, sudah ada tim TI yang sudah mapan. Dan tim ini dalam ritme kebiasaan lama (kecuali Agile) telah bekerja bersama selama bertahun-tahun dan sulit terbakar dengan keinginan (lagi) untuk mengubah sesuatu. Semuanya cocok untuk semua orang, kecuali, tentu saja, kepemimpinan. Yang melihat bahwa dalam perangkat lunak mereka setiap kesalahan terus-menerus dialirkan, ketentuan rilis versi baru digeser.
Tentu saja, satu opsi lagi dapat diasumsikan ketika seseorang datang ke perusahaan dengan pengalaman di DevOps, dengan jelas menggambarkan apa masalahnya dan bagaimana cara memecahkannya. Dan siapa yang mampu menyampaikan pendapatnya kepada pimpinan. Namun, jangan berharap untuk keajaiban paman.
Dan banyak yang istirahat tentang ini. Mereka mulai mengatakan bahwa tidak ada yang mendukung mereka, bahwa tidak mungkin untuk mengimplementasikan apa pun di rawa ini, dan kemudian pergi ke perusahaan lain, di mana siklus berulang.
Ternyata lingkaran setan? Tidak, secara bertahap kami sampai pada kesimpulan bahwa dengan bisnis Anda hanya perlu berbicara dalam bahasa yang ia pahami - dalam bahasa uang. Untuk melakukan ini, kita mendapatkan kartu truf utama dari kaki lengan yang lebar - pengurangan Time-to-Market. Kami perlu menunjukkan bahwa berkat DevOps, versi baru dari produk akan dirilis seperti hotcakes. Dan mari kita tinggalkan semua manfaat di atas dari penerapan DevOps untuk presentasi akhir, yang akan kita buat untuk direktur, ketika semuanya berjalan lancar. Banyak yang akan mengatakan bahwa ini terlalu jelas. Tidak!
Kita membutuhkan sesuatu yang akan membawa kita waktu minimum dan sumber daya (setelah semua, tidak ada yang akan memungkinkan untuk menghapuskan man-bulan untuk implementasi DevOps tertentu dan tidak akan membeli server baru yang mendesak bagi kita), tetapi pada saat yang sama akan memberikan hasil yang sangat nyata (itu sebenarnya akan mengurangi Waktu untuk -Pasar).
Pertama, Anda perlu menemukan hambatan, tetapi itu selalu satu (langkah pertama dalam teori kendala Goldratt). Setelah keberhasilan penerapan Agile (dan semua ini masuk akal hanya setelah implementasi Agile), dalam hal pengembangan perangkat lunak, mereka masih harus menguji secara manual. Bahkan dengan kelompok bebas-tangan, pengujian regresi bisa memakan waktu dua hingga tiga minggu. Dan dari cara penguji "suka" melakukan pengujian regresi, saya tahu segalanya.
Jadi, kami telah menentukan bahwa pengujian adalah hambatan. Maka Anda harus mulai dengan otomasinya. Banyak yang akan memperhatikan: lebih mudah diucapkan daripada dilakukan. Jutaan baris kode telah ditulis, dan ada baiknya jika programmer setidaknya membahas sesuatu dengan unit test. Faktanya, semuanya tidak seseram kelihatannya. Pengalaman menunjukkan bahwa 80% dari hasil yang sukses dalam bentuk penurunan serius Time-to-Market dicapai melalui 20% upaya. Itu adalah berapa banyak biaya pengujian otomatisasi dalam kasus kami.
Benar-benar menurut hukum Pareto, ya.
Dan yang paling penting, Anda dapat mulai menguji otomatisasi sebelum manajemen setuju untuk mengalokasikan sumber daya untuk implementasi bagian-bagian DevOps yang tersisa. Proyek percontohan kecil yang dapat dilakukan sendiri dalam satu hingga dua minggu.
Tetapi pada saat yang sama, situasi seperti itu memberi kita peluang untuk memenangkan kemenangan yang spektakuler dan, paling penting, cepat. Setelah itu, dengan memiliki sikap positif dan berkah dari kepemimpinan, Anda sudah dapat meminta uang dan sumber daya.
Untuk mulai dengan, tentu saja, programmer Anda sudah menggunakan beberapa jenis perangkat lunak server untuk build harian. Itu bisa TeamCity, atau Bambu, atau Jenkins, - itu tidak masalah. Yang utama adalah bahwa sudah ada bagian dari otomatisasi dan perlu digunakan, dan jika tidak, maka mudah untuk menggunakannya dalam sehari.
Pertama, Anda perlu mengotomatisasi tes asap. Tetapi bagaimana memahami apa yang diotomatisasi? Ya, lihat saja apa yang Anda bangkrut ketika Anda memposting perubahan selama enam bulan terakhir.
Selanjutnya, Anda perlu membuat beberapa tes untuk memverifikasi operasi proses bisnis utama. Bagaimana cara mengidentifikasi mereka? Untuk menanyakan analis / direktur / perwakilan bisnis Anda, gangguan seperti apa yang dilarikan oleh direktur yang marah ke kantor programmer dan menetapkan tugas dengan suara yang terangkat.
Seminggu, yah, maksimal dua untuk membuat tes seperti itu. Hasilnya adalah umpan balik yang sangat cepat untuk kesalahan global.
Dan sementara proyek dalam mode konsep terbukti, Anda tidak perlu menyiapkan penyebaran server otomatis yang sama untuk pengujian dan busur lainnya, tetapi lakukan semuanya secara manual. Keindahan ini kemudian dapat dilakukan dengan kesenangan bersama dengan admin.
Apa yang akan menyebabkan ini tidak sulit ditebak. Pengembang akan segera melihat (dan memperbaiki) kesalahan mereka. Penguji akan terhindar dari rutinitas melakukan tes panjang dan membosankan untuk regresi. Mereka akan memiliki beberapa hari untuk menguji hanya bagian-bagian dari kode yang dapat diedit. Ya persis. Dan jika tidak, maka kembalilah ke permulaan dan bicarakan lagi dengan analis / direktur / perwakilan bisnis tentang proses kritis bisnis.
Kemacetan yang menyebabkan rem utama muncul telah dieliminasi. Sekarang yang tersisa adalah merilis beberapa rilis baru ke lingkungan yang produktif, menghapus statistik "tadinya" dan pergi dengan angka-angka ini kepada manajemen. Untung!
Setelah kemenangan yang meyakinkan, Anda sudah dapat berbicara tentang otomatisasi penyebaran tegakan (setidaknya untuk pengujian). Selanjutnya, minta dana untuk pemantauan dan kesenangan DevOps lainnya. Harus diingat bahwa komponen yang tersisa dari sistem tidak akan lagi memiliki efek wow untuk bisnis.
Contoh studio
Di akhir posting, saya pikir akan tepat untuk memberikan contoh proyek yang berhasil diselesaikan untuk implementasi DevOps, yang dilaksanakan oleh perusahaan kami.
Satu pengecer besar memiliki sekitar 20% dari bisnis di toko online. Pada saat yang sama, perlu bereaksi sangat cepat terhadap situasi pasar dan membuat perubahan yang diperlukan pada perangkat lunak. Dan seringkali. Dan berkualitas tinggi. Setiap jamb di situs dapat mempengaruhi konversi, risikonya dinyatakan dalam uang nyata.
Untuk mengurangi waktu memperbarui dan meningkatkan kualitas, platform autotest khusus dibuat di mana tugas rutin untuk menguji perubahan dan regresi situs web diotomatiskan. Selain itu, proses interaksi kelompok pengujian otomatis dengan tim pengembangan dibangun. Ini memungkinkan pengembang untuk segera mengidentifikasi dan memperbaiki cacat pada sistem yang diperbarui, tanpa menunggu pengujian penerimaan akhir.
Perwakilan pengecer menemukan pengalaman sukses dan memutuskan untuk menerapkannya pada produk perangkat lunak lain.
Dan contoh kecil lainnya, tetapi dari praktik satu perusahaan asuransi besar. Sebelum pengenalan otomatisasi uji, rilis dirilis setiap enam bulan. Bukan karena bisnis begitu menuntut - itu hanya tidak berhasil lebih sering. Dan pelanggan hanya ingin. Jadi, dua bulan setelah dimulainya pengenalan alat pengujian otomatis, tim TI beralih ke iterasi rilis rilis dua minggu.
Cukup signifikan untuk mulai melakukan ini, bukan?
Sergey Stramnov, arsitek presale Pusat Solusi Perangkat Lunak Jet Infosystems