Gambar: UnsplashHalo semuanya! Kami adalah insinyur otomatisasi dari
Positive Technologies dan kami mendukung pengembangan produk perusahaan: kami mendukung seluruh jalur perakitan dari pengembang yang melakukan serangkaian kode untuk menerbitkan produk jadi dan lisensi pada server yang diperbarui. Secara informal, kami disebut insinyur DevOps. Pada artikel ini kami ingin berbicara tentang tahapan teknologi dari proses produksi perangkat lunak, tentang bagaimana kita melihatnya dan bagaimana kita mengklasifikasikannya.
Dari materi Anda akan belajar tentang kompleksitas mengoordinasikan pengembangan multi-produk, tentang apa itu alur kerja dan bagaimana hal itu membantu untuk mengatur dan mereplikasi solusi, apa tahapan dan langkah utama dari proses pengembangan, bagaimana tanggung jawab dibagi antara DevOps dan tim di perusahaan kami.
Tentang Kekacauan dan DevOps
Perhatikan secara singkat bahwa konsep DevOps mencakup alat dan layanan pengembangan, serta metodologi dan praktik terbaik untuk penggunaannya. Kami akan memilih
tujuan global dari memperkenalkan ide-ide DevOps di perusahaan kami: ini adalah pengurangan yang konsisten dalam biaya produksi dan pemeliharaan produk secara kuantitatif (jam kerja atau jam mesin, CPU, RAM, Disk, dll.). Cara paling sederhana dan paling jelas untuk mengurangi total biaya pengembangan di tingkat perusahaan adalah untuk
meminimalkan biaya melakukan tugas-tugas serial yang khas pada semua tahap produksi. Tetapi apa tahapan-tahapan ini, bagaimana membedakannya dari proses umum, langkah-langkah apa yang mereka ikuti?
Ketika sebuah perusahaan mengembangkan satu produk, semuanya lebih atau kurang jelas: biasanya ada peta jalan umum dan skema pengembangan. Tetapi apa yang harus dilakukan ketika lini produk meluas dan ada lebih banyak produk? Pada pandangan pertama, mereka memiliki proses dan jalur perakitan yang serupa dan permainan "temukan perbedaan X" dalam log dan skrip dimulai. Dan jika sudah ada 5+ proyek dalam pengembangan aktif dan Anda memerlukan dukungan untuk beberapa versi yang dikembangkan selama beberapa tahun? Apakah kita ingin menggunakan kembali sebanyak mungkin solusi dalam konveyor produk atau apakah kita siap mengeluarkan uang untuk pengembangan yang unik untuk masing-masing?
Bagaimana menemukan keseimbangan antara keunikan dan serialitas solusi?
Masalah-masalah ini mulai muncul di hadapan kita lebih sering sejak 2015. Jumlah produk tumbuh, dan kami mencoba untuk meminimalkan ekspansi kami dari departemen otomasi kami (DevOps), yang mendukung lini perakitan produk-produk ini. Pada saat yang sama, saya ingin sebanyak mungkin solusi untuk mereplikasi antar produk. Lagi pula, mengapa melakukan hal yang sama dalam sepuluh produk dengan cara yang berbeda?
Direktur Pengembangan : "Guys, bisakah kita mengevaluasi apa yang dilakukan DevOps untuk produk?"
Kami : "Kami tidak tahu, kami tidak mengajukan pertanyaan seperti itu kepada diri kami sendiri, tetapi indikator apa yang harus dipertimbangkan?"
Direktur Pengembangan : โDan siapa yang tahu! Pikirkan ... "
Seperti di film terkenal: "Ke hotel saya! .." - "Uh ... Maukah Anda menunjukkan jalan?" Berpikir, kami sampai pada kesimpulan bahwa pertama-tama Anda harus memutuskan keadaan akhir produk; ini adalah tujuan pertama kami.
Jadi, bagaimana Anda menganalisis selusin produk dengan tim yang cukup besar dari 10 hingga 200 orang dan menentukan metrik yang dapat diukur saat mereplikasi solusi?
1: 0 untuk Chaos, atau DevOps di bagian bahu
Kami mulai dengan upaya untuk menerapkan diagram IDEF0 dan berbagai diagram proses bisnis dari seri BPwin. Kebingungan dimulai setelah kotak kelima dari tahap selanjutnya dari proyek berikutnya, dan kotak-kotak ini untuk setiap proyek dapat ditarik ke ekor python panjang di bawah 50+ langkah. Saya sedih dan ingin melolong ke bulan - itu tidak cocok secara umum.
Tugas Produksi Khas
Membuat model proses produksi adalah pekerjaan yang sangat rumit dan melelahkan: Anda perlu mengumpulkan, memproses, dan menganalisis banyak data di berbagai departemen dan rantai produksi. Anda dapat membaca lebih lanjut tentang ini di artikel "
Pemodelan proses produksi di perusahaan IT ."
Ketika kami mulai memodelkan proses produksi kami, kami mengejar tujuan khusus - untuk menyampaikan kepada setiap karyawan yang terlibat dalam pengembangan produk perusahaan kami, dan kepada manajer proyek:
- bagaimana produk dan komponennya, mulai dari garis kode berkomitmen, menjangkau pelanggan dalam bentuk pemasang dan pembaruan,
- sumber daya apa yang disediakan untuk setiap tahap produksi produk,
- layanan apa yang terlibat di setiap tahap,
- bagaimana bidang tanggung jawab dibedakan untuk setiap tahap,
- kontrak apa yang ada pada input dan output dari setiap tahap.
Dengan mengklik gambar akan terbuka dalam ukuran penuhPekerjaan kami di perusahaan dibagi menjadi beberapa area fungsional. Arah infrastruktur terlibat dalam mengoptimalkan operasi semua sumber daya "besi" dari departemen, serta mengotomatiskan penyebaran mesin virtual dan lingkungan mereka. Arah pemantauan menyediakan pemantauan kesehatan layanan 24/7; Kami juga menyediakan pemantauan sebagai layanan untuk pengembang. Arah alur kerja memberi tim alat untuk mengelola proses pengembangan dan pengujian, menganalisis status kode, dan untuk memperoleh analisis proyek. Dan akhirnya, webdev menyediakan rilis penerbitan pada server pembaruan GUS dan FLUS, serta produk lisensi menggunakan layanan LicenseLab. Untuk mendukung pipa produksi, kami menyiapkan dan mengelola berbagai layanan dukungan untuk pengembang (Anda dapat mendengarkan cerita tentang beberapa di antaranya di mitaps lama:
Op! DevOps! 2016 dan
Op! DevOps! 2017 ). Kami juga mengembangkan alat otomatisasi internal, termasuk
solusi open source .
Selama lima tahun terakhir, banyak dari jenis yang sama dan operasi rutin telah terakumulasi dalam pekerjaan kami, dan dari pengembang kami dari departemen lain terutama datang apa yang disebut
tugas standar , solusi yang diotomatisasi secara keseluruhan atau sebagian, tidak menyebabkan kesulitan bagi pemain dan tidak memerlukan banyak pekerjaan. Bersama dengan arahan terkemuka, kami menganalisis tugas-tugas tersebut dan mampu membedakan kategori tertentu dari pekerjaan atau
tahap produksi , membagi tahapan menjadi langkah-langkah yang tidak dapat dibagi, dan
rantai teknologi produksi terdiri dari beberapa tahap.
Contoh paling sederhana dari rantai teknologi adalah tahapan perakitan, penyebaran, dan pengujian setiap produk kami di perusahaan. Pada gilirannya, misalnya, fase build terdiri dari banyak langkah khas yang terpisah: mengunduh sumber dari GitLab, menyiapkan dependensi dan pustaka pihak ketiga, pengujian unit dan analisis kode statis, menjalankan skrip build pada GitLab CI, menerbitkan artefak ke repositori di Artifactory dan menghasilkan catatan rilis melalui alat internal kami ChangelogBuilder.
Anda dapat membaca tentang tugas-tugas DevOps pada artikel kami yang lain di Habrรฉ: "
Pengalaman pribadi: bagaimana sistem Integrasi Berkelanjutan kami terlihat " dan "
Otomatisasi proses pengembangan: bagaimana kami menerapkan ide-ide DevOps dalam Teknologi Positif ".
Banyak rantai produksi yang khas membentuk
proses produksi . Pendekatan standar untuk menggambarkan proses adalah dengan menggunakan model IDEF0 fungsional.
Contoh pemodelan proses CI produksi
Kami memberikan perhatian khusus pada pengembangan proyek model untuk sistem integrasi berkelanjutan. Ini memungkinkan kami untuk mencapai penyatuan proyek, menyoroti
skema perakitan rilis yang disebut
dengan kemajuan .
Begini cara kerjanya. Semua proyek terlihat khas: mereka menyertakan konfigurasi rakitan yang termasuk dalam repositori snapshot pada Artifactory, setelah itu mereka dikerahkan dan diuji di bangku tes, dan kemudian dipromosikan ke repositori rilis. Layanan Artifactory adalah titik distribusi tunggal dari semua artefak bangunan antara tim dan layanan lainnya.
Jika kami sangat menyederhanakan dan menggeneralisasikan skema rilis kami, maka itu termasuk langkah-langkah berikut:
- perakitan produk lintas platform,
- penyebaran untuk menguji berdiri,
- menjalankan tes fungsional dan lainnya,
- promosi bangunan yang diuji untuk melepaskan repositori di Artifactory,
- Publikasikan rilis rilis untuk memperbarui server,
- pengiriman rakitan dan pembaruan produksi,
- Luncurkan instalasi dan pembaruan produk.
Sebagai contoh, pertimbangkan model teknologi dari skema rilis tipikal ini (selanjutnya hanya disebut sebagai Model) dalam bentuk model IDEF0 fungsional. Ini mencerminkan tahapan utama proses CI kami. Model IDEF0 menggunakan apa yang disebut
notasi ICOM (Input-Control-Output-Mechanism) untuk menggambarkan sumber daya apa yang digunakan pada setiap tahap, berdasarkan pada aturan dan persyaratan apa, apa yang dilakukan, apa yang dihasilkan dan apa mekanisme dan layanan apa, layanan atau orang mengimplementasikan tahapan tertentu.
Dengan mengklik gambar akan terbuka dalam ukuran penuhSebagai aturan, dalam model fungsional lebih mudah untuk menguraikan dan merinci deskripsi proses. Tetapi dengan peningkatan jumlah elemen, untuk memahami di dalamnya sesuatu menjadi semakin sulit. Tetapi dalam pengembangan nyata ada juga langkah-langkah tambahan: pemantauan, sertifikasi produk, otomatisasi proses kerja dan lain-lain. Karena masalah penskalaan, kami meninggalkan deskripsi seperti itu.
Kelahiran harapan
Dalam satu buku, mereka menemukan peta lama Soviet yang menggambarkan proses teknologi (yang, kebetulan, sekarang digunakan di banyak perusahaan milik negara dan universitas). Tunggu, tunggu, karena kami juga memiliki proses teknologi! .. Ada tahapan, hasil, metrik, persyaratan, indikator, dan sebagainya ... Mengapa tidak mencoba menerapkan peta teknologi ke konveyor produk kami? Ada perasaan: โIni dia! Kami menemukan utas yang tepat, saatnya menariknya dengan baik! โ
Dalam tabel sederhana, kami memutuskan untuk memperbaiki produk dalam kolom, dan dalam barisan tahapan teknologi dan langkah-langkah konveyor produk. Tahapan - ini adalah sesuatu yang besar, misalnya, tahap perakitan produk. Dan langkah-langkahnya adalah sesuatu yang lebih kecil dan lebih rinci, misalnya, langkah mengunduh kode sumber ke server build atau langkah menyusun kode.
Di persimpangan baris dan kolom peta, kami meletakkan status untuk tahap dan produk tertentu. Untuk status, banyak negara telah ditentukan:
- Tidak ada data - atau tidak praktis. Penting untuk melakukan analisis relevansi tahap dalam produk. Entah analisis telah dilakukan, tetapi tahap saat ini tidak diperlukan atau tidak dibenarkan secara ekonomi.
- Ditunda - atau tidak relevan saat ini. Diperlukan tahapan dalam konveyor, tetapi tahun ini tidak ada kekuatan untuk implementasi.
- Dijadwalkan . Tahap ini direncanakan untuk implementasi untuk tahun ini.
- Diimplementasikan . Tahap dalam conveyor diimplementasikan dalam volume yang diperlukan.
Mengisi tabel mulai bijaksana. Pada awalnya, tahapan dan langkah dari satu proyek diklasifikasikan dan status dicatat untuk mereka. Kemudian mereka mengambil proyek berikutnya, mencatat status di dalamnya dan menambahkan langkah dan langkah yang tidak ada dalam proyek sebelumnya. Sebagai hasilnya, kami mendapatkan tahapan dan langkah dari seluruh conveyor produksi kami dan status mereka dalam proyek tertentu. Ternyata sesuatu yang mirip dengan matriks kompetensi konveyor produk. Kami menyebut matriks semacam itu sebagai peta teknologi.
Dengan menggunakan peta teknologi, kami secara metrologis berkoordinasi dengan rencana kerja dan target tahunan tim yang ingin kami capai bersama: tahapan mana yang kami tambahkan tahun ini ke proyek dan yang akan kami tunda nanti. Juga, dalam proses kerja, kami mungkin menerima peningkatan pada tahap yang kami lakukan hanya untuk satu produk. Kemudian kami memperluas peta kami dan memperkenalkan peningkatan ini sebagai tahap atau langkah baru, kemudian kami menganalisis setiap produk dan mencari tahu cara untuk mereplikasi peningkatan tersebut.
Mereka mungkin keberatan dengan kita: โIni, tentu saja, semuanya baik, hanya seiring waktu jumlah langkah dan tahapan menjadi sangat besar. Bagaimana bisa? "
Kami telah memperkenalkan deskripsi standar dan cukup lengkap tentang persyaratan untuk setiap tahap dan langkah, sehingga mereka dipahami oleh semua orang di dalam perusahaan. Seiring waktu, ketika memperkenalkan peningkatan, suatu langkah dapat diserap dalam langkah atau langkah lain - maka mereka akan "runtuh". Pada saat yang sama, semua persyaratan dan nuansa teknologi cocok dengan persyaratan tahap atau langkah generalisasi.
Bagaimana cara mengevaluasi efek dari replikasi keputusan? Kami menggunakan pendekatan yang sangat sederhana: kami mengaitkan biaya modal awal untuk pelaksanaan tahap baru dengan total biaya makanan tahunan, dan kemudian membaginya menjadi semua saat direplikasi.
Bagian dari pembangunan sudah tercermin sebagai langkah dan langkah di peta. Kita dapat memengaruhi pengurangan biaya produk melalui pengenalan otomatisasi untuk tahap-tahap tertentu. Setelah itu, kami mempertimbangkan perubahan karakteristik kualitatif, metrik kuantitatif, dan keuntungan yang diterima oleh tim (dalam jam kerja atau penghematan mesin).
Bagan alur proses
Jika kita mengambil semua tahapan dan langkah kita, menyandikan dengan tag dan memperluas dalam satu rantai, maka itu akan menjadi sangat panjang dan tidak bisa dipahami (hanya "ekor ular sanca" yang kita bicarakan di awal artikel):
[Production] โ [InfMonitoring] โ [SourceCodeControl] โ [Prepare] โ [PrepareLinuxDocker] โ [PrepareWinDocker] โ [Build] โ [PullSourceCode] โ [PrepareDep] โ [UnitTest] โ [CodeCoverage] โ [StaticAnalyze] โ [BuildScenario] โ [PushToSnapshot] โ [ChangelogBuilder] โ [Deploy] โ [PrepareTestStand] โ [PullTestCode] โ [PrepareTestEnv] โ [PullArtifact] โ [DeployArtifact] โ [Test] โ [BVTTest] โ [SmokeTest] โ [FuncTest] โ [LoadTest] โ [IntegrityTest] โ [DeliveryTest] โ [MonitoringStands] โ [TestManagement] โ [Promote] โ [QualityTag] โ [MoveToRelease] โ [License] โ [Publish] โ [PublishGUSFLUS] โ [ControlVisibility] โ [Install] โ [LicenseActivation] โ [RequestUpdates] โ [PullUpdates] โ [InitUpdates] โ [PrepareEnv] โ [InstallUpdates] โ [Telemetry] โ [Workflow] โ [Communication] โ [Certification] โ [CISelfSufficiency]
Ini adalah tahap merakit produk [Build], menggunakan mereka untuk menguji server [Menyebarkan], menguji [Uji], mempromosikan majelis untuk merilis repositori berdasarkan pengujian [Promosikan], membuat dan menerbitkan lisensi [Lisensi], menerbitkan [Mempublikasikan] di server pembaruan GUS dan mengirimkan ke server pembaruan FLUS, menginstal dan memperbarui komponen produk pada infrastruktur pelanggan menggunakan Manajemen Konfigurasi Produk [Instal], serta mengumpulkan telemetri [Telemetri] dari produk yang diinstal.
Selain itu, ada tahapan terpisah: memantau keadaan infrastruktur [InfMonitoring], kontrol versi kode sumber [SourceCodeControl], mempersiapkan lingkungan perakitan [Mempersiapkan], manajemen proyek [Workflow], menyediakan tim dengan alat komunikasi [Komunikasi], sertifikasi produk [Sertifikasi] dan menyediakan swasembada dari CI-proses [CISelfSufficiency] (misalnya, independensi majelis dari Internet). Kami bahkan tidak akan mempertimbangkan lusinan langkah dalam proses kami, karena mereka sangat spesifik.
Akan jauh lebih mudah untuk memahami dan melihat keseluruhan proses produksi, jika disajikan dalam bentuk
peta teknologi ; ini adalah tabel di mana langkah-langkah produksi individu dan langkah-langkah terurai Model ditulis dalam baris, dan kolom menggambarkan apa yang dilakukan pada setiap langkah atau langkah. Penekanan utama ditempatkan pada sumber daya yang menyediakan setiap tahap, dan pembatasan bidang tanggung jawab.
Peta bagi kami adalah semacam classifier. Ini mencerminkan sebagian besar teknologi produksi pangan. Berkat itu, menjadi lebih mudah bagi tim otomat kami untuk berinteraksi dengan pengembang dan bersama-sama merencanakan implementasi tahapan otomasi, serta memahami tenaga kerja dan sumber daya apa (manusia dan "besi") yang dibutuhkan.
Di dalam perusahaan kami, peta secara otomatis dihasilkan dari template jinja dalam bentuk file HTML biasa, dan kemudian diunggah ke server Halaman GitLab. Tangkapan layar dengan contoh peta yang dibuat sepenuhnya dapat dilihat di
sini .
Dengan mengklik gambar akan terbuka dalam ukuran penuhSingkatnya, diagram alir adalah gambaran umum dari proses produksi, yang dengan jelas mencerminkan blok dengan fungsi tipikal.
Struktur perutean kami
Peta terdiri dari beberapa bagian:
- Heading area - di sini adalah gambaran umum dari peta, konsep dasar diperkenalkan, sumber daya dasar dan hasil dari proses produksi ditentukan.
- Panel informasi - di sini Anda dapat mengontrol tampilan data untuk masing-masing produk, memberikan ringkasan langkah-langkah dan langkah-langkah yang diambil untuk semua produk secara umum.
- Peta teknologi - deskripsi tabular dari proses teknologi. Di peta:
- semua tahapan, langkah dan kodenya diberikan;
- Deskripsi singkat dan lengkap dari tahapan diberikan;
- Sumber daya input dan layanan yang digunakan pada setiap tahap diindikasikan;
- hasil dari setiap tahap dan langkah individu ditunjukkan;
- Area tanggung jawab untuk setiap langkah dan langkah ditunjukkan;
- sumber daya teknis yang teridentifikasi, seperti HDD (SSD), RAM, vCPU, dan jam kerja yang diperlukan untuk mendukung pekerjaan pada tahap ini, baik pada saat ini - sebuah fakta, dan di masa depan - sebuah rencana;
- untuk setiap produk diindikasikan langkah-langkah teknologi atau langkah-langkah untuk itu telah diterapkan, direncanakan untuk implementasi, tidak relevan atau tidak diterapkan.
Pengambilan keputusan berdasarkan peta teknologi
Setelah memeriksa peta, dimungkinkan untuk mengambil beberapa tindakan - tergantung pada peran karyawan di perusahaan (manajer pengembangan, manajer produk, pengembang atau penguji):
- memahami langkah-langkah apa yang hilang dalam produk atau proyek nyata, dan menilai kebutuhan untuk penerapannya;
- untuk membedakan zona tanggung jawab antara beberapa departemen jika mereka bekerja pada tahapan yang berbeda;
- menyetujui kontrak di pintu masuk dan keluar dari tahapan;
- mengintegrasikan tahap kerja Anda ke dalam proses pengembangan keseluruhan;
- lebih akurat menilai kebutuhan sumber daya yang menyediakan masing-masing tahapan.
Ringkas semua hal di atas
Routing bersifat universal, dapat dikembangkan, dan mudah dirawat. Jauh lebih mudah untuk mengembangkan dan mempertahankan deskripsi proses dalam bentuk ini daripada dalam model IDEF0 akademik yang ketat. Selain itu, deskripsi tabular lebih sederhana, lebih akrab dan terstruktur lebih baik daripada model fungsional.
Untuk implementasi teknis dari langkah-langkah ini, kami bertanggung jawab untuk alat CrossBuilder internal khusus - alat antar pemain antara sistem CI, layanan dan infrastruktur. Pengembang tidak perlu melihat sepedanya: dalam sistem CI kami cukup menjalankan salah satu skrip (tugas yang disebut) dari alat CrossBuilder, yang akan mengeksekusinya dengan benar dengan mempertimbangkan kekhasan infrastruktur kami.
Ringkasan
Artikel itu ternyata cukup panjang, tetapi ini tidak bisa dihindari dalam deskripsi pemodelan proses yang kompleks. Pada akhirnya, saya ingin memperbaiki secara singkat ide-ide utama kami:
- Tujuan dari memperkenalkan ide-ide DevOps di perusahaan kami adalah pengurangan yang konsisten dalam biaya produksi dan pemeliharaan produk perusahaan secara kuantitatif (jam kerja atau jam mesin, vCPU, RAM, Disk).
- Cara untuk mengurangi total biaya pengembangan adalah dengan meminimalkan biaya untuk melakukan tugas-tugas serial yang khas: tahapan dan langkah dari proses teknologi.
- Tugas khas adalah tugas yang solusinya diotomatisasi seluruhnya atau sebagian, tidak menyebabkan kesulitan bagi pemain dan tidak memerlukan biaya tenaga kerja yang signifikan.
- Proses produksi terdiri dari tahapan, tahapan dibagi menjadi langkah-langkah yang tidak dapat dibagi, yang merupakan tugas-tugas tipikal dari skala dan volume yang berbeda.
- Dari tugas-tugas yang berbeda, kita sampai pada rantai teknologi yang kompleks dan model multi-level dari proses produksi, yang dapat digambarkan oleh model IDEF0 fungsional atau diagram alur yang lebih sederhana.
- Routing adalah presentasi tabular dari langkah-langkah dan langkah-langkah proses pembuatan. Yang paling penting: peta memungkinkan Anda melihat seluruh proses, dalam potongan besar dengan kemungkinan perincian.
- Berdasarkan peta teknologi, adalah mungkin untuk menilai kebutuhan untuk implementasi tahapan dalam produk tertentu, untuk membedakan antara bidang tanggung jawab, untuk menyetujui kontrak untuk input dan output dari tahapan, untuk lebih akurat menilai kebutuhan sumber daya.
Dalam artikel-artikel berikut, kami akan berbicara lebih rinci tentang alat teknis apa yang digunakan untuk mengimplementasikan tahapan teknologi tertentu pada peta kami.
Penulis artikel: