Entah bagaimana kami menempatkan pelanggan pada satu objek sistem manajemen dokumen elektronik. Dan kemudian ke objek lain. Dan satu lagi. Dan pada hari keempat dan kelima. Mereka begitu terbawa hingga mencapai 10 objek yang didistribusikan. Kuat terjadi ... terutama ketika kami sampai pada pengiriman perubahan. Sebagai bagian dari pasokan ke sirkuit produktif untuk 5 skenario sistem pengujian, dibutuhkan 10 jam dan 6-7 karyawan sebagai hasilnya. Biaya seperti itu memaksa kami untuk mengirimkan sesedikit mungkin. Setelah tiga tahun beroperasi, kami tidak tahan dan memutuskan untuk membumbui proyek dengan sejumput DevOps.
Sekarang semua pengujian lulus dalam 3 jam, dan 3 orang berpartisipasi di dalamnya: seorang insinyur dan dua penguji. Perbaikan secara jelas dinyatakan dalam jumlah dan mengarah pada pengurangan TTM tercinta. Dalam pengalaman kami, ada jauh lebih banyak pelanggan yang bisa dibantu oleh DevOps daripada mereka yang mengetahuinya. Oleh karena itu, untuk membuat DevOps lebih dekat dengan orang-orang, kami telah mengembangkan konstruktor sederhana, yang akan kami bahas lebih rinci dalam posting ini.
Sekarang kita akan menceritakan lebih detail. Dalam satu perusahaan energi di 10 fasilitas besar, sistem manajemen dokumen teknis sedang digunakan. Tidak mudah untuk muncul dalam proyek sebesar ini tanpa DevOps, karena sebagian besar tenaga kerja manual sangat menunda pekerjaan dan juga mengurangi kualitas - semua pekerjaan manual penuh dengan kesalahan. Di sisi lain, ada proyek di mana instalasi adalah satu, tetapi perlu bahwa semuanya bekerja secara otomatis, terus-menerus dan tanpa kegagalan - misalnya, sistem manajemen dokumen yang sama dalam organisasi monolitik besar. Jika tidak, seseorang akan membuat pengaturan secara manual, lupakan instruksi penyebaran - dan sebagai hasilnya, pengaturan akan hilang pada prod dan semuanya akan macet.
Biasanya kami bekerja dengan pelanggan melalui kontrak, dalam hal ini minat kami sedikit berbeda. Pelanggan melihat proyek secara ketat dalam anggaran dan TK. Sulit untuk menjelaskan kepadanya manfaat dari berbagai praktik DevOps yang bukan bagian dari TK. Dan jika dia tertarik dengan rilis cepat dengan nilai tambah untuk bisnis, dalam membangun pipa otomatisasi?
Sayangnya, dalam bekerja dengan nilai yang disetujui sebelumnya, minat ini tidak selalu mungkin ditemukan. Dalam praktik kami, ada kasus ketika kami harus mengambil pengembangan kontraktor yang tidak jujur dan tidak akurat. Itu adalah horor: tidak ada kode sumber yang sebenarnya, basis kode dari sistem yang sama pada instalasi yang berbeda berbeda, dokumentasi sebagian hilang, sebagian berkualitas buruk. Tentu saja, pelanggan tidak memiliki kontrol sumber, perakitan, rilis, dll.
Sejauh ini, tidak semua orang tahu tentang DevOps, tetapi ada baiknya berbicara tentang keuntungannya, tentang penghematan sumber daya yang nyata, mata menyala untuk semua pelanggan. Jadi ada semakin banyak permintaan yang melibatkan DevOps dari waktu ke waktu. Di sini, agar dapat dengan mudah berbicara bahasa yang sama dengan pelanggan, kita perlu dengan cepat menghubungkan masalah-masalah bisnis dan praktik-praktik DevOps, yang akan membantu membangun jalur pengembangan yang sesuai.
Jadi, kami memiliki satu set masalah di satu sisi, ada pengetahuan, praktik dan alat DevOps di sisi lain. Mengapa tidak berbagi pengalaman dengan semua orang?
Buat Konstruktor DevOps
Agile memiliki manifesto sendiri. ITIL memiliki metodologi sendiri. DevOps kurang beruntung - belum memperoleh template dan standar. Meskipun
beberapa berusaha menentukan tingkat kematangan perusahaan berdasarkan penilaian terhadap pengembangan dan metode operasi mereka.
Untungnya, perusahaan Gartner yang terkenal jahat pada tahun 2014
mengumpulkan dan menganalisis praktik utama DevOps dan hubungan di antara mereka. Berdasarkan ini, saya merilis infografik:
Kami menganggapnya sebagai dasar
konstruktor kami. Di masing-masing dari empat area ada satu set alat - kami mengumpulkan mereka dalam database, mengidentifikasi titik integrasi yang paling populer, diidentifikasi dan mekanisme optimasi yang sesuai. Secara total,
36 praktik dan 115 alat ternyata, seperempat di antaranya adalah perangkat lunak terbuka atau gratis. Selanjutnya, kita akan berbicara tentang apa yang kita lakukan di setiap area dan, misalnya, bagaimana penerapannya dalam proyek untuk membuat alur kerja teknis dari mana kita memulai posting.
Prosesnya
Dalam proyek EDMS terkenal, sistem manajemen dokumentasi teknis dikerahkan sesuai dengan skema yang sama di masing-masing 10 fasilitas. Instalasi mencakup 4 server: server database, server aplikasi, pengindeksan teks lengkap, dan manajemen konten. Dalam instalasi, mereka bekerja dalam satu node, berlokasi di pusat data di fasilitas. Semua objek sedikit berbeda dalam infrastruktur, tetapi ini tidak mengganggu interaksi global.
Pertama, menurut praktik DevOps, kami mengotomatiskan infrastruktur secara lokal, kemudian kami membawa pengiriman ke sirkuit uji, dan kemudian ke produktivitas pelanggan. Setiap proses berjalan selangkah demi selangkah. Pengaturan lingkungan ditetapkan dalam sistem kode sumber, dengan mempertimbangkan distribusi yang dikumpulkan untuk pembaruan otomatis. Jika terjadi perubahan dalam konfigurasi, insinyur hanya perlu membuat perubahan yang sesuai dengan sistem kontrol versi - dan kemudian pembaruan otomatis akan berlalu tanpa masalah.
Berkat pendekatan ini, proses pengujian telah sangat disederhanakan. Sebelumnya, ada penguji dalam proyek yang hanya melakukan itu secara manual memperbarui tribun. Sekarang mereka hanya datang, melihat bahwa semuanya telah bekerja dan terlibat dalam hal-hal yang lebih bermanfaat. Setiap pembaruan diuji secara otomatis - dari permukaan hingga otomatisasi skenario bisnis. Hasilnya disajikan sebagai laporan terpisah di TestRail.
Budaya
Eksperimen berkelanjutan paling baik dijelaskan dengan desain uji. Menguji sistem yang belum ada adalah karya kreatif. Saat menulis rencana pengujian, Anda perlu memahami cara menguji dengan benar, cabang mana yang harus dilalui. Dan juga menemukan keseimbangan antara waktu dan anggaran untuk menentukan jumlah cek yang optimal. Penting untuk memilih dengan tepat pengujian yang diperlukan, mempertimbangkan bagaimana pengguna akan berinteraksi dengan sistem, memperhitungkan lingkungan dan kemungkinan faktor eksternal. Anda tidak dapat melakukannya tanpa eksperimen terus menerus.
Sekarang tentang budaya interaksi. Dulu ada dua pihak yang bertikai - insinyur dan pengembang. Pengembang mengatakan:
"Kami tidak peduli bagaimana ini dimulai. Anda adalah insinyur, Anda pintar, membuatnya beroperasi tanpa gangguan .
" Insinyur menjawab:
"Anda pengembang terlalu gegabah. Biarkan kami lebih berhati-hati, dan kami akan lebih jarang merilis Anda. Karena setiap kali Anda memberi kami kode berlubang, dan cara kami berinteraksi tidak jelas .
" Ini adalah masalah interaksi budaya yang, dari sudut pandang DevOps, terstruktur secara berbeda. Di sini Anda memiliki insinyur dan pengembang yang merupakan bagian dari satu tim yang bertujuan untuk terus berubah, tetapi pada saat yang sama perangkat lunak yang dapat diandalkan.
Pada skala satu tim, spesialis ditetapkan untuk saling membantu. Bagaimana sebelumnya? Misalnya, semacam manual penyebaran sedang dipersiapkan, halaman di 50. Insinyur membacanya, tidak mengerti sesuatu, bersumpah dan meminta pengembang untuk berkomentar pukul tiga pagi. Pengembang berkomentar dan juga bersumpah - pada akhirnya, tidak ada yang senang. Plus, tentu saja, ada beberapa kesalahan, karena Anda tidak akan mengingat semuanya dalam instruksi. Dan sekarang insinyur, bersama dengan pengembang, sedang menulis skrip untuk penyebaran otomatis dari perangkat lunak aplikasi infrastruktur. Dan mereka berbicara satu sama lain dalam bahasa yang hampir sama.
Orang
Ukuran tim ditentukan oleh tingkat pembaruan. Tim direkrut selama pembentukan pasokan, termasuk mereka yang ingin dari tim proyek umum. Kemudian, rencana pembaruan ditulis dengan tanggung jawab untuk setiap tahap, saat tim mengeksekusi, lapor. Semua anggota tim dapat dipertukarkan. Sebagai bagian dari tim, kami juga memiliki pengembang keamanan, tetapi ia hampir tidak pernah terhubung.
Teknologi
Dalam skema untuk teknologi, beberapa poin disorot, tetapi di bawahnya ada banyak teknologi - dengan deskripsi mereka Anda dapat merilis seluruh buku. Jadi kami akan menyoroti yang paling menarik.
Infrastruktur sebagai kode
Sekarang, mungkin, Anda tidak akan mengejutkan siapa pun dengan konsep ini, tetapi sebelum deskripsi infrastruktur banyak yang harus diinginkan.
Insinyur melihat dengan ngeri pada instruksi , lingkungan pengujian unik, mereka dirawat dan dihargai, partikel debu diterbangkan dari mereka.
Sekarang tidak ada yang takut untuk bereksperimen. Ada gambar dasar dari mesin virtual, ada skenario yang sudah jadi untuk menyebarkan lingkungan. Semua templat dan skrip disimpan dalam sistem kontrol versi dan diperbarui dengan cepat. Sebelumnya, ketika perlu untuk mengirimkan paket ke stand, celah konfigurasi muncul. Sekarang Anda hanya perlu menambahkan baris dalam kode sumber.
Selain skenario infrastruktur dan jalur pipa, pendekatan Dokumentasi sebagai Kode juga digunakan untuk dokumentasi. Berkat ini, mudah untuk menghubungkan orang-orang baru ke proyek, memperkenalkan mereka ke sistem dengan fungsi yang dijelaskan, misalnya, dalam rencana pengujian, dan juga menggunakan kembali kasus uji.
Pengiriman dan Pemantauan Berkelanjutan
Dalam artikel terakhir kami tentang DevOps, kami berbicara tentang bagaimana kami memilih alat untuk mengimplementasikan pengiriman dan pemantauan yang berkelanjutan. Seringkali tidak perlu menulis ulang apa pun - cukup menggunakan skrip yang ditulis sebelumnya, membangun integrasi antar komponen dengan benar dan membuat konsol manajemen bersama. Dan semua proses dapat dimulai dengan satu tombol atau jadwal.
Ada berbagai konsep dalam bahasa Inggris, Pengiriman Berkelanjutan dan Penerapan Berkelanjutan. Keduanya dapat diterjemahkan sebagai "pengiriman kontinu", tetapi pada kenyataannya ada sedikit perbedaan di antara mereka. Dalam proyek kami untuk manajemen dokumen teknis dari perusahaan energi terdistribusi, Pengiriman digunakan, alih-alih, ketika instalasi untuk penjualan dilakukan berdasarkan perintah. Dalam Penyebaran, instalasi otomatis. Pengiriman Berkelanjutan dalam proyek ini umumnya menjadi
bagian sentral dari DevOps .
Secara umum, dengan mengumpulkan parameter tertentu, Anda dapat dengan jelas memahami mengapa praktik DevOps bermanfaat. Dan untuk menyampaikan ini kepada pimpinan, yang sangat menyukai angka. Jumlah total peluncuran, waktu pelaksanaan tahapan skrip, proporsi peluncuran yang sukses - semua ini secara langsung memengaruhi waktu favorit semua orang untuk memasarkan, yaitu waktu mulai dari berkomitmen ke sistem kontrol versi hingga rilis versi pada lingkungan yang produktif. Dengan diperkenalkannya alat yang diperlukan, insinyur menerima indikator berharga melalui surat, dan manajer proyek melihatnya di dasbor. Jadi Anda bisa langsung menghargai manfaat alat baru. Dan Anda dapat mencobanya di infrastruktur Anda menggunakan konstruktor DevOps.
Kami tidak akan menipu: sebagai permulaan, ia menjadi berguna bagi kami. Seperti yang sudah kami katakan, pelanggan perlu berbicara bahasa yang sama, dan dengan bantuan konstruktor DevOps kami dapat dengan cepat menguraikan dasar untuk percakapan seperti itu. Para profesional bisnis akan dapat mengevaluasi diri mereka sendiri apa yang mereka butuhkan, dan dengan demikian berkembang lebih cepat. Kami mencoba membuat konstruktor sedetail mungkin, menambahkan banyak deskripsi sehingga setiap pengguna mengerti apa yang dia pilih.
Format desainer memungkinkan Anda untuk mempertimbangkan pengalaman perusahaan yang ada dalam proses membangun dan otomatisasi. Anda tidak perlu memecah semuanya dan membangun kembali jika Anda hanya dapat memilih solusi yang terintegrasi secara normal ke dalam proses yang ada yang hanya dapat mengisi kesenjangan.
Mungkin pengembangan Anda telah pindah ke tingkat yang lebih tinggi dan alat kami akan tampak terlalu "kapten". Tetapi kami menemukan itu berguna untuk diri kita sendiri dan berharap itu bermanfaat bagi beberapa pembaca. Kami mengingatkan Anda
tautan ke konstruktor - jika ada, Anda mendapatkan sirkuit segera setelah memasukkan data sumber. Kami akan berterima kasih atas umpan balik dan tambahannya.