Kami pernah memasok sistem manajemen dokumen elektronik kepada pelanggan di satu fasilitas. Dan kemudian ke objek lain. Dan satu lagi. Dan yang keempat, dan yang kelima. Kami begitu terbawa hingga mencapai 10 objek yang dibagikan. Ternyata sangat kuat... terutama ketika kami harus memberikan perubahan. Sebagai bagian dari pengiriman ke sirkuit produksi, 5 skenario sistem pengujian pada akhirnya membutuhkan 10 jam dan 6-7 karyawan. Biaya sebesar itu memaksa kami untuk melakukan pengiriman sejarang mungkin. Setelah tiga tahun beroperasi, kami tidak tahan dan memutuskan untuk meningkatkan proyek ini dengan sedikit DevOps.
Sekarang semua pengujian berlangsung dalam 3 jam, dan 3 orang berpartisipasi di dalamnya: seorang insinyur dan dua penguji. Peningkatan tersebut jelas terlihat dalam angka dan mengarah pada pengurangan TTM yang sangat digemari. Berdasarkan pengalaman kami, terdapat lebih banyak pelanggan yang dapat memperoleh manfaat dari DevOps dibandingkan mereka yang mengetahuinya. Oleh karena itu, untuk mendekatkan DevOps kepada orang-orang, kami telah mengembangkan konstruktor sederhana, yang akan kami bahas lebih detail di postingan ini.
Sekarang mari kita beri tahu Anda lebih detail. Sebuah perusahaan energi menerapkan sistem manajemen dokumen teknis di 10 fasilitas besar. Tidak mudah untuk menavigasi proyek sebesar ini tanpa DevOps, karena sebagian besar pekerjaan manual sangat menunda pekerjaan dan juga mengurangi kualitas - semua pekerjaan manual penuh dengan kesalahan. Di sisi lain, ada proyek di mana hanya ada satu instalasi, tetapi semuanya harus bekerja secara otomatis, terus-menerus dan tanpa kegagalan - misalnya, sistem aliran dokumen yang sama di organisasi monolitik besar. Jika tidak, seseorang akan membuat pengaturan secara manual, melupakan instruksi penerapan - dan akibatnya, dalam produksi, pengaturan akan hilang dan semuanya akan runtuh.
Biasanya kami bekerja dengan pelanggan melalui kontrak, dan dalam hal ini minat kami sedikit berbeda. Pelanggan melihat proyek secara ketat sesuai anggaran dan spesifikasi teknis. Sulit untuk menjelaskan kepadanya manfaat berbagai praktik DevOps yang tidak disertakan dalam spesifikasi teknis. Bagaimana jika dia tertarik pada rilis cepat dengan nilai bisnis tambahan, atau dalam membangun jalur otomatisasi?
Sayangnya, ketika bekerja dengan biaya yang telah disetujui sebelumnya, minat ini tidak selalu ditemukan. Dalam praktik kami, ada kasus ketika kami harus mengambil pengembangan dari kontraktor yang tidak bermoral dan ceroboh. Ini sangat buruk: tidak ada kode sumber terkini, basis kode dari sistem yang sama berbeda pada instalasi yang berbeda, dokumentasi sebagian tidak ada, dan sebagian kualitasnya buruk. Tentu saja, pelanggan tidak memiliki kendali atas kode sumber, perakitan, rilis, dll.
Sejauh ini, tidak semua orang tahu tentang DevOps, tetapi begitu kita berbicara tentang kelebihannya, tentang penghematan sumber daya yang nyata, mata semua pelanggan berbinar. Jadi jumlah permintaan yang menyertakan DevOps meningkat seiring waktu. Di sini, agar dapat dengan mudah berbicara bahasa yang sama dengan pelanggan, kita perlu dengan cepat menghubungkan masalah bisnis dan praktik DevOps yang akan membantu membangun jalur pengembangan yang sesuai.
Jadi, kami memiliki serangkaian masalah di satu sisi, kami memiliki pengetahuan, praktik, dan alat DevOps di sisi lain. Mengapa tidak berbagi pengalaman dengan semua orang?
Membuat konstruktor DevOps
Agile memiliki manifestonya sendiri. ITIL memiliki metodologinya sendiri. DevOps kurang beruntung karena belum memperoleh templat dan standar. Meskipun menentukan kematangan perusahaan berdasarkan penilaian terhadap perkembangan dan praktik operasionalnya.
Untungnya, perusahaan terkenal Gartner pada tahun 2014 dan menganalisis praktik utama DevOps dan hubungan di antara praktik tersebut. Berdasarkan ini, saya merilis infografis:
Kami menganggapnya sebagai dasar untuk kami . Masing-masing dari empat area tersebut memiliki seperangkat alat - kami mengumpulkannya ke dalam database, mengidentifikasi yang paling populer, mengidentifikasi titik integrasi, dan mekanisme pengoptimalan yang sesuai. Ternyata totalnya 36 praktik dan 115 alat, seperempatnya merupakan perangkat lunak open source atau gratis. Selanjutnya, kita akan berbicara tentang apa yang telah kami capai di setiap bidang dan, sebagai contoh, tentang bagaimana hal ini diterapkan dalam proyek untuk membuat manajemen dokumen teknis, yang dengannya kami memulai postingan ini.
Процессы
Dalam proyek EDMS yang terkenal kejam, sistem manajemen dokumentasi teknis diterapkan sesuai dengan skema yang sama di masing-masing dari 10 objek. Instalasi mencakup 4 server: server database, server aplikasi, pengindeksan teks lengkap, dan manajemen konten. Dalam instalasinya, mereka beroperasi dalam satu node dan berlokasi di pusat data di fasilitas. Semua objek sedikit berbeda dalam infrastruktur, tetapi hal ini tidak mengganggu interaksi global.
Pertama, berdasarkan praktik DevOps, kami mengotomatisasi infrastruktur secara lokal, lalu kami membawa pengiriman ke sirkuit pengujian, dan kemudian ke produk pelanggan. Setiap proses dikerjakan langkah demi langkah. Pengaturan lingkungan ditetapkan dalam sistem kode sumber, dengan mempertimbangkan kit distribusi yang dikompilasi untuk pembaruan otomatis. Jika terjadi perubahan konfigurasi, teknisi hanya perlu membuat perubahan yang sesuai pada sistem kontrol versi - dan pembaruan otomatis akan berlangsung tanpa masalah.
Berkat pendekatan ini, proses pengujian menjadi sangat disederhanakan. Sebelumnya, proyek ini memiliki penguji yang tidak melakukan apa pun selain memperbarui stand secara manual. Sekarang mereka datang saja, melihat semuanya berfungsi dan melakukan hal-hal yang lebih bermanfaat. Setiap pembaruan diuji secara otomatis - mulai dari tingkat permukaan hingga otomatisasi skenario bisnis. Hasilnya diposting sebagai laporan terpisah di TestRail.
Культура
Eksperimen berkelanjutan paling baik dijelaskan melalui contoh desain pengujian. Menguji sistem yang belum ada adalah pekerjaan kreatif. Saat menulis rencana pengujian, Anda perlu memahami cara menguji dengan benar dan cabang mana yang harus diikuti. Dan juga menemukan keseimbangan antara waktu dan anggaran untuk menentukan jumlah cek yang optimal. Penting untuk memilih pengujian yang diperlukan dengan tepat, memikirkan bagaimana pengguna akan berinteraksi dengan sistem, memperhitungkan lingkungan dan kemungkinan faktor eksternal. Tidak mungkin dilakukan tanpa eksperimen terus-menerus.
Sekarang tentang budaya interaksi. Sebelumnya, ada dua pihak yang berlawanan - insinyur dan pengembang. Pengembang berkata: “Kami tidak peduli bagaimana ini akan diluncurkan. Anda adalah insinyur, Anda cerdas, pastikan semuanya beroperasi tanpa kegagalan". Para insinyur menjawab: “Kalian para pengembang terlalu ceroboh. Mari lebih berhati-hati, dan kami akan lebih jarang memutar rilis Anda. Karena setiap kali Anda memberi kami kode yang bocor, kami tidak jelas cara berinteraksinya.”. Ini adalah masalah interaksi budaya yang disusun secara berbeda dari perspektif DevOps. Di sini, baik insinyur maupun pengembang adalah bagian dari satu tim yang berfokus pada perangkat lunak yang terus berubah namun pada saat yang sama dapat diandalkan.
Dalam tim yang sama, para spesialis bertekad untuk saling membantu. Seperti sebelumnya? Misalnya, beberapa instruksi penerapan yang tebal sedang disiapkan, panjangnya sekitar 50 halaman, Insinyur membacanya, tidak memahami sesuatu, mengutuk dan meminta pengembang pada jam tiga pagi untuk berkomentar. Pengembang berkomentar dan juga mengutuk - pada akhirnya, tidak ada yang senang. Ditambah lagi, tentu saja, ada beberapa kesalahan, karena Anda tidak dapat mengingat semua yang ada dalam instruksi. Dan sekarang sang insinyur, bersama dengan pengembang, sedang menulis skrip untuk penerapan otomatis infrastruktur perangkat lunak aplikasi. Dan mereka berbicara satu sama lain dalam bahasa yang hampir sama.
Orang-orang
Besar kecilnya tim ditentukan oleh cakupan pembaruan. Tim direkrut selama pembentukan pengiriman; termasuk mereka yang tertarik dari tim proyek umum. Kemudian rencana pembaruan ditulis dengan mereka yang bertanggung jawab untuk setiap tahapan, dan tim melaporkan perkembangannya. Semua anggota tim dapat dipertukarkan. Sebagai bagian dari tim, kami juga memiliki pengembang cadangan, namun dia hampir tidak pernah harus terhubung.
Teknologi
Dalam diagram teknologi, beberapa poin disorot, tetapi di bawahnya terdapat banyak teknologi - Anda dapat menerbitkan seluruh buku beserta deskripsinya. Jadi kami akan menyoroti yang paling menarik.
Infrastruktur sebagai Kode
Sekarang, mungkin konsep ini tidak akan mengejutkan siapa pun, tetapi deskripsi infrastruktur sebelumnya masih jauh dari yang diinginkan. , lingkungan pengujiannya unik, dihargai dan dihargai, partikel debunya tertiup angin.
Saat ini tidak ada yang takut untuk bereksperimen. Ada gambar dasar mesin virtual, ada skenario siap pakai untuk lingkungan penerapan. Semua templat dan skrip disimpan dalam sistem kontrol versi dan segera diperbarui. Sebelumnya, ketika perlu mengirimkan paket ke stand, muncul celah konfigurasi. Sekarang Anda hanya perlu menambahkan satu baris ke kode sumber.
Selain skrip infrastruktur dan saluran pipa, pendekatan Dokumentasi sebagai Kode juga digunakan untuk dokumentasi. Berkat ini, mudah untuk menghubungkan orang-orang baru ke proyek, memperkenalkan mereka ke sistem berdasarkan fungsi yang dijelaskan, misalnya, dalam rencana pengujian, dan juga menggunakan kembali kasus uji.
Pengiriman dan pemantauan berkelanjutan
tentang DevOps, kami membahas tentang cara kami memilih alat untuk menerapkan pengiriman dan pemantauan berkelanjutan. Seringkali tidak perlu menulis ulang apa pun - cukup menggunakan skrip yang ditulis sebelumnya, membangun integrasi antar komponen dengan benar, dan membuat konsol manajemen umum. Dan semua proses dapat diluncurkan menggunakan satu tombol atau jadwal.
Dalam bahasa Inggris ada konsep yang berbeda, Continuous Delivery dan Continuous Deployment. Keduanya bisa diterjemahkan sebagai “pengiriman berkelanjutan”, namun nyatanya ada sedikit perbedaan di antara keduanya. Dalam proyek kami untuk aliran dokumen teknis perusahaan energi terdistribusi, Pengiriman digunakan - ketika instalasi untuk produksi dilakukan berdasarkan perintah. Dalam Deployment, instalasi terjadi secara otomatis. Pengiriman Berkelanjutan dalam proyek ini secara umum telah menjadi bagian tengah DevOps.
Secara umum, dengan mengumpulkan parameter tertentu, Anda dapat memahami dengan jelas mengapa praktik DevOps berguna. Dan sampaikan hal ini kepada manajemen yang sangat menyukai angka. Jumlah total peluncuran, waktu eksekusi tahapan skrip, pangsa peluncuran yang berhasil - semua ini secara langsung memengaruhi waktu favorit semua orang untuk memasarkan, yaitu waktu mulai dari penerapan sistem kontrol versi hingga rilis versi pada a lingkungan produksi. Dengan penerapan alat yang diperlukan, para insinyur menerima indikator berharga melalui surat, dan manajer proyek melihatnya di dasbor. Dengan cara ini Anda dapat segera mengevaluasi manfaat alat-alat baru. Dan Anda dapat mencobanya di infrastruktur Anda menggunakan desainer DevOps.
Siapa yang membutuhkan kita ?
Jangan berpura-pura: sebagai permulaan, dia berguna bagi kita. Seperti yang telah kami katakan, Anda perlu berbicara dalam bahasa yang sama dengan pelanggan, dan dengan bantuan desainer DevOps kami dapat dengan cepat membuat sketsa dasar percakapan semacam itu. Spesialis bisnis akan dapat menilai sendiri apa yang mereka butuhkan dan dengan demikian berkembang lebih cepat. Kami mencoba membuat perancangnya sedetail mungkin, menambahkan banyak deskripsi sehingga setiap pengguna memahami apa yang dia pilih.
Format perancang memungkinkan Anda memperhitungkan perkembangan perusahaan saat ini dalam membangun proses dan otomatisasi. Tidak perlu merobohkan semuanya dan membangunnya kembali jika Anda hanya dapat memilih solusi yang terintegrasi dengan baik dengan proses yang ada dan dapat mengisi kekosongan yang ada.
Mungkin perkembangan Anda telah berpindah ke tingkat yang lebih tinggi dan alat kami akan tampak terlalu “kapten”. Namun kami merasa bermanfaat bagi diri kami sendiri dan berharap dapat bermanfaat bagi sebagian pembaca. Kami mengingatkan Anda kepada perancang - jika ada, Anda menerima diagram segera setelah memasukkan data awal. Kami akan berterima kasih atas masukan dan tambahan Anda.
Sumber: www.habr.com