Kami pernah membekalkan sistem pengurusan dokumen elektronik kepada pelanggan di satu kemudahan. Dan kemudian ke objek lain. Dan satu lagi. Dan pada yang keempat, dan pada yang kelima. Kami terlalu terbawa-bawa sehingga kami mencapai 10 objek yang diedarkan. Ia ternyata hebat... terutamanya apabila kami perlu menyampaikan perubahan. Sebagai sebahagian daripada penghantaran ke litar pengeluaran, 5 senario sistem ujian akhirnya memerlukan 10 jam dan 6-7 pekerja. Kos sedemikian memaksa kami membuat penghantaran sejarang mungkin. Selepas tiga tahun beroperasi, kami tidak tahan dan memutuskan untuk menyemarakkan projek dengan secubit DevOps.
Kini semua ujian berlaku dalam masa 3 jam, dan 3 orang mengambil bahagian di dalamnya: seorang jurutera dan dua penguji. Penambahbaikan dinyatakan dengan jelas dalam angka dan membawa kepada pengurangan dalam TTM yang sangat digemari. Mengikut pengalaman kami, terdapat lebih ramai pelanggan yang boleh mendapat manfaat daripada DevOps berbanding mereka yang mengetahuinya. Oleh itu, untuk membawa DevOps lebih dekat dengan orang ramai, kami telah membangunkan pembina mudah, yang akan kami bincangkan dengan lebih terperinci dalam siaran ini.
Sekarang mari beritahu anda dengan lebih terperinci. Satu syarikat tenaga sedang menggunakan sistem pengurusan dokumen teknikal di 10 kemudahan besar. Bukan mudah untuk menavigasi projek skala ini tanpa DevOps, kerana sebahagian besar buruh manual sangat melambatkan kerja dan juga mengurangkan kualiti - semua kerja manual penuh dengan ralat. Sebaliknya, terdapat projek di mana hanya terdapat satu pemasangan, tetapi semuanya perlu berfungsi secara automatik, sentiasa dan tanpa kegagalan - contohnya, sistem aliran dokumen yang sama dalam organisasi monolitik yang besar. Jika tidak, seseorang akan membuat tetapan secara manual, melupakan arahan penggunaan - dan akibatnya, dalam pengeluaran tetapan akan hilang dan semuanya akan runtuh.
Biasanya kami bekerja dengan pelanggan melalui kontrak, dan dalam kes ini minat kami sedikit berbeza. Pelanggan melihat projek dengan ketat mengikut bajet dan spesifikasi teknikal. Sukar untuk menerangkan kepadanya manfaat pelbagai amalan DevOps yang tidak termasuk dalam spesifikasi teknikal. Bagaimana jika dia berminat dengan keluaran pantas dengan nilai perniagaan tambahan, atau dalam membina saluran paip automasi?
Malangnya, apabila bekerja dengan kos yang telah diluluskan, minat ini tidak selalu dijumpai. Dalam amalan kami, terdapat satu kes apabila kami terpaksa mengambil pembangunan kontraktor yang tidak bertanggungjawab dan cuai. Ia amat mengerikan: tiada kod sumber terkini, asas kod sistem yang sama berbeza pada pemasangan yang berbeza, dokumentasi sebahagiannya tidak hadir, dan sebahagiannya daripada kualiti yang teruk. Sudah tentu, pelanggan tidak mempunyai kawalan ke atas kod sumber, pemasangan, keluaran, dll.
Setakat ini, tidak semua orang tahu tentang DevOps, tetapi sebaik sahaja kita bercakap tentang kelebihannya, tentang penjimatan sumber sebenar, mata semua pelanggan bersinar. Jadi bilangan permintaan yang termasuk DevOps semakin meningkat dari semasa ke semasa. Di sini, untuk mudah bercakap bahasa yang sama dengan pelanggan, kami perlu menghubungkan masalah perniagaan dan amalan DevOps dengan cepat yang akan membantu membina saluran pembangunan yang sesuai.
Jadi, kami mempunyai satu set masalah di satu pihak, dan pengetahuan, amalan dan alatan DevOps di pihak yang lain. Mengapa tidak berkongsi pengalaman dengan semua orang?
Mencipta pembina DevOps
Agile mempunyai manifestonya sendiri. ITIL mempunyai metodologi tersendiri. DevOps kurang bernasib baik - ia masih belum memperoleh templat dan piawaian. Walaupun menentukan kematangan syarikat berdasarkan penilaian terhadap pembangunan dan amalan operasi mereka.
Nasib baik, syarikat terkenal Gartner pada tahun 2014 dan menganalisis amalan DevOps utama dan hubungan antara mereka. Berdasarkan ini, saya mengeluarkan maklumat grafik:
Kami mengambilnya sebagai asas untuk kami . Setiap satu daripada empat kawasan mempunyai satu set alatan - kami mengumpulkannya ke dalam pangkalan data, mengenal pasti yang paling popular, mengenal pasti titik integrasi dan mekanisme pengoptimuman yang sesuai. Secara keseluruhannya ternyata 36 amalan dan 115 alatan, satu perempat daripadanya ialah perisian sumber terbuka atau percuma. Seterusnya, kami akan bercakap tentang apa yang telah kami capai dalam setiap kawasan dan, sebagai contoh, tentang bagaimana ini dilaksanakan dalam projek untuk mencipta pengurusan dokumen teknikal, yang dengannya kami memulakan siaran.
Proses
Dalam projek EDMS yang terkenal, sistem pengurusan dokumentasi teknikal telah digunakan mengikut skema yang sama pada setiap 10 objek. Pemasangan termasuk 4 pelayan: pelayan pangkalan data, pelayan aplikasi, pengindeksan teks penuh dan pengurusan kandungan. Dalam pemasangan, mereka beroperasi dalam satu nod dan terletak di pusat data di kemudahan. Semua objek berbeza sedikit dalam infrastruktur, tetapi ini tidak mengganggu interaksi global.
Pertama, mengikut amalan DevOps, kami mengautomasikan infrastruktur secara tempatan, kemudian kami membawa penghantaran ke litar ujian, dan kemudian ke produk pelanggan. Setiap proses telah diusahakan langkah demi langkah. Tetapan persekitaran ditetapkan dalam sistem kod sumber, dengan mengambil kira kit pengedaran yang disusun untuk pengemaskinian automatik. Dalam kes perubahan konfigurasi, jurutera hanya perlu membuat perubahan yang sesuai pada sistem kawalan versi - dan kemudian kemas kini automatik akan berlaku tanpa masalah.
Terima kasih kepada pendekatan ini, proses ujian telah dipermudahkan. Sebelum ini, projek itu mempunyai penguji yang tidak melakukan apa-apa selain mengemas kini dirian secara manual. Sekarang mereka hanya datang, melihat bahawa semuanya berfungsi dan melakukan perkara yang lebih berguna. Setiap kemas kini diuji secara automatik - dari peringkat permukaan kepada automasi senario perniagaan. Hasilnya disiarkan sebagai laporan berasingan dalam TestRail.
Kebudayaan
Percubaan berterusan dijelaskan dengan baik melalui contoh reka bentuk ujian. Menguji sistem yang belum wujud lagi adalah kerja kreatif. Apabila menulis rancangan ujian, anda perlu memahami cara menguji dengan betul dan cabang mana yang perlu diikuti. Dan juga cari keseimbangan antara masa dan belanjawan untuk menentukan bilangan cek yang optimum. Adalah penting untuk memilih dengan tepat ujian yang diperlukan, fikirkan bagaimana pengguna akan berinteraksi dengan sistem, mengambil kira persekitaran dan kemungkinan faktor luaran. Ia adalah mustahil untuk dilakukan tanpa percubaan berterusan.
Sekarang tentang budaya interaksi. Sebelum ini, terdapat dua pihak yang bertentangan - jurutera dan pemaju. Pemaju berkata: βKami tidak kisah bagaimana ia akan dilancarkan. Anda jurutera, anda bijak, pastikan ia beroperasi tanpa kegagalan". Jurutera menjawab: βKamu pembangun terlalu cuai. Mari kita lebih berhati-hati, dan kami akan memainkan keluaran anda lebih jarang. Kerana setiap kali anda memberi kami kod yang bocor, kami tidak jelas cara berinteraksi.". Ini ialah isu interaksi budaya yang distrukturkan secara berbeza daripada perspektif DevOps. Di sini, kedua-dua jurutera dan pembangun adalah sebahagian daripada satu pasukan yang memberi tumpuan kepada perubahan yang sentiasa berubah, tetapi pada masa yang sama perisian yang boleh dipercayai.
Dalam pasukan yang sama, pakar bertekad untuk membantu antara satu sama lain. Seperti dahulu? Sebagai contoh, beberapa arahan penggunaan tebal sedang disediakan, kira-kira 50 muka surat panjang. Jurutera membacanya, tidak memahami sesuatu, mengutuk dan meminta pembangun pada pukul tiga pagi untuk mengulas. Pemaju mengulas dan juga mengutuk - akhirnya, tiada siapa yang gembira. Selain itu, secara semula jadi, terdapat beberapa kesilapan, kerana anda tidak dapat mengingati segala-galanya dalam arahan. Dan kini jurutera, bersama-sama dengan pembangun, sedang menulis skrip untuk penggunaan automatik infrastruktur perisian aplikasi. Dan mereka bercakap antara satu sama lain secara praktikal dalam bahasa yang sama.
Orang
Saiz pasukan ditentukan oleh skop kemas kini. Pasukan ini diambil semasa pembentukan penghantaran; ia termasuk mereka yang berminat daripada pasukan projek am. Kemudian pelan kemas kini ditulis dengan mereka yang bertanggungjawab untuk setiap peringkat, dan pasukan melaporkan semasa ia berlangsung. Semua ahli pasukan boleh ditukar ganti. Sebagai sebahagian daripada pasukan, kami juga mempunyai pembangun sandaran, tetapi dia hampir tidak perlu menyambung.
Teknologi
Dalam rajah teknologi, beberapa perkara diserlahkan, tetapi di bawahnya terdapat sekumpulan teknologi - anda boleh menerbitkan keseluruhan buku dengan penerangannya. Jadi kami akan menyerlahkan yang paling menarik.
Infrastruktur sebagai Kod
Sekarang, mungkin, konsep ini tidak akan mengejutkan sesiapa pun, tetapi sebelum ini penerangan tentang infrastruktur meninggalkan banyak yang perlu diingini. , persekitaran ujian adalah unik, mereka dihargai dan dihargai, zarah habuk diterbangkan darinya.
Pada masa kini tiada siapa yang takut untuk bereksperimen. Terdapat imej asas mesin maya, terdapat senario siap sedia untuk menggunakan persekitaran. Semua templat dan skrip disimpan dalam sistem kawalan versi dan dikemas kini dengan segera. Sebelum ini, apabila perlu menghantar pakej ke pendirian, jurang konfigurasi muncul. Kini anda hanya perlu menambah baris pada kod sumber.
Selain skrip infrastruktur dan saluran paip, pendekatan Dokumentasi sebagai Kod juga digunakan untuk dokumentasi. Terima kasih kepada ini, adalah mudah untuk menghubungkan orang baru ke projek, memperkenalkan mereka kepada sistem berdasarkan fungsi yang diterangkan, contohnya, dalam pelan ujian, dan juga menggunakan semula kes ujian.
Penyampaian dan pemantauan berterusan
tentang DevOps, kami bercakap tentang cara kami memilih alatan untuk melaksanakan penghantaran dan pemantauan berterusan. Selalunya tidak perlu menulis semula apa-apa - cukup untuk menggunakan skrip yang ditulis sebelum ini, membina integrasi antara komponen dengan betul dan mencipta konsol pengurusan biasa. Dan semua proses boleh dilancarkan menggunakan satu butang atau jadual.
Dalam bahasa Inggeris terdapat konsep yang berbeza, Penghantaran Berterusan dan Penggunaan Berterusan. Kedua-duanya boleh diterjemahkan sebagai "penyampaian berterusan", tetapi sebenarnya terdapat sedikit perbezaan di antara mereka. Dalam projek kami untuk aliran dokumen teknikal syarikat tenaga teragih, sebaliknya, Penghantaran digunakan - apabila pemasangan untuk pengeluaran berlaku atas arahan. Dalam Deployment, pemasangan berlaku secara automatik. Penghantaran Berterusan dalam projek ini secara amnya telah menjadi bahagian tengah DevOps.
Secara umum, dengan mengumpulkan parameter tertentu, anda boleh memahami dengan jelas sebab amalan DevOps berguna. Dan sampaikan ini kepada pihak pengurusan, yang sangat sukakan nombor. Jumlah bilangan pelancaran, masa pelaksanaan peringkat skrip, bahagian pelancaran yang berjaya - semua ini secara langsung mempengaruhi masa kegemaran semua orang untuk memasarkan, iaitu, masa dari komitmen kepada sistem kawalan versi kepada keluaran versi pada persekitaran pengeluaran. Dengan pelaksanaan alat yang diperlukan, jurutera menerima penunjuk berharga melalui mel, dan pengurus projek melihatnya di papan pemuka. Dengan cara ini anda boleh menilai dengan segera faedah alatan baharu. Dan anda boleh mencubanya pada infrastruktur anda menggunakan pereka DevOps.
Siapa yang memerlukan kami ?
Jangan kita berpura-pura: sebagai permulaan, dia menjadi berguna kepada kita. Seperti yang telah kami katakan, anda perlu bercakap bahasa yang sama dengan pelanggan, dan dengan bantuan pereka DevOps kami boleh dengan cepat melakarkan asas untuk perbualan sedemikian. Pakar perniagaan akan dapat menilai sendiri apa yang mereka perlukan dan dengan itu berkembang lebih cepat. Kami cuba membuat pereka bentuk sedetail mungkin, menambahkan sekumpulan huraian supaya mana-mana pengguna memahami perkara yang dia pilih.
Format pereka bentuk membolehkan anda mengambil kira perkembangan sedia ada syarikat dalam proses pembinaan dan automasi. Tidak perlu meruntuhkan segala-galanya dan membinanya semula jika anda hanya boleh memilih penyelesaian yang disepadukan dengan baik dengan proses sedia ada dan yang hanya boleh mengisi jurang.
Mungkin perkembangan anda telah beralih ke tahap yang lebih tinggi dan alat kami akan kelihatan terlalu "kapten". Tetapi kami dapati ia berguna untuk diri kami sendiri dan berharap ia berguna kepada sebahagian pembaca. Kami mengingatkan anda kepada pereka bentuk - jika ada, anda menerima gambar rajah sejurus selepas memasukkan data awal. Kami akan berterima kasih atas maklum balas dan penambahan anda.
Sumber: www.habr.com