Gambar:
Halo semua! Kami adalah insinyur otomasi dari perusahaan dan kami mendukung pengembangan produk perusahaan: kami mendukung seluruh pipa perakitan mulai dari komit satu baris kode oleh pengembang hingga publikasi produk jadi dan lisensi di server pembaruan. Secara informal, kami disebut insinyur DevOps. Pada artikel ini, kami ingin berbicara tentang tahapan teknologi dari proses produksi perangkat lunak, bagaimana kami melihatnya dan bagaimana kami mengklasifikasikannya.
Dari materi tersebut Anda akan belajar tentang kompleksitas koordinasi pengembangan multi-produk, tentang apa itu peta teknologi dan bagaimana membantu merampingkan dan mereplikasi solusi, apa saja tahapan dan langkah utama dari proses pengembangan, bagaimana bidang tanggung jawab antara DevOps dan tim di perusahaan kami.
Tentang Kekacauan dan DevOps
Secara singkat, konsep DevOps mencakup alat dan layanan pengembangan, serta metodologi dan praktik terbaik untuk penggunaannya. Mari pilih yang global tujuannya dari implementasi 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 termudah dan paling jelas untuk mengurangi keseluruhan biaya pengembangan di tingkat seluruh perusahaan adalah meminimalkan biaya melakukan tugas serial yang khas pada semua tahap produksi. Tetapi apa tahapan-tahapan ini, bagaimana memisahkannya dari proses umum, terdiri dari langkah-langkah apa?
Ketika sebuah perusahaan mengembangkan satu produk, semuanya kurang lebih jelas: biasanya ada peta jalan dan skema pengembangan yang sama. Tapi apa yang harus dilakukan ketika lini produk berkembang dan ada lebih banyak produk? Sekilas, mereka memiliki proses dan jalur perakitan yang serupa, dan permainan "temukan perbedaan X" dalam log dan skrip dimulai. Tetapi bagaimana jika sudah ada 5+ proyek dalam pengembangan aktif dan diperlukan dukungan untuk beberapa versi yang dikembangkan selama beberapa tahun? Apakah kita ingin menggunakan kembali sebanyak mungkin solusi dalam alur produk atau apakah kita siap mengeluarkan uang untuk pengembangan unik untuk masing-masing?
Bagaimana menemukan keseimbangan antara keunikan dan solusi serial?
Pertanyaan-pertanyaan ini semakin sering muncul di hadapan kami sejak 2015. Jumlah produk bertambah, dan kami mencoba memperluas departemen otomasi kami (DevOps), yang mendukung jalur perakitan produk ini, seminimal mungkin. Pada saat yang sama, kami ingin mereplikasi sebanyak mungkin solusi antar produk. Lagi pula, mengapa melakukan hal yang sama pada sepuluh produk dengan cara yang berbeda?
Direktur Pengembangan: "Teman-teman, bisakah kita mengevaluasi apa yang dilakukan DevOps untuk produk?"
Kita: “Kami tidak tahu, kami tidak menanyakan pertanyaan seperti itu, tetapi indikator apa yang harus dipertimbangkan?”
Direktur Pengembangan: "Siapa tahu! Memikirkan…"
Seperti dalam film terkenal itu: "Saya di hotel! .." - "Uh ... Bisakah Anda menunjukkan jalannya?" Setelah direnungkan, kami sampai pada kesimpulan bahwa pertama-tama kami perlu memutuskan keadaan akhir produk; ini menjadi tujuan pertama kami.
Jadi, bagaimana Anda menganalisis selusin produk dengan tim yang cukup besar dari 10 hingga 200 orang dan menentukan metrik terukur saat mereplikasi solusi?
1:0 mendukung Kekacauan, atau DevOps di tulang belikat
Kami mulai dengan mencoba menerapkan diagram IDEF0 dan berbagai diagram proses bisnis dari seri BPwin. Kebingungan dimulai setelah kotak kelima dari tahap berikutnya dari proyek berikutnya, dan kotak ini untuk setiap proyek dapat digambar di ekor python panjang di bawah 50+ langkah. Saya merasa sedih dan ingin melolong ke bulan - itu tidak cocok secara umum.
Tugas produksi yang khas
Pemodelan proses produksi adalah pekerjaan yang sangat kompleks dan melelahkan: Anda perlu mengumpulkan, memproses, dan menganalisis banyak data dari berbagai departemen dan rantai produksi. Anda dapat membaca lebih lanjut tentang ini di artikel "'.
Saat kami mulai memodelkan proses produksi kami, kami memiliki tujuan khusus - untuk menyampaikan kepada setiap karyawan yang terlibat dalam pengembangan produk perusahaan kami, dan kepada manajer proyek:
- bagaimana produk dan komponennya, mulai dari komit baris kode, menjangkau pelanggan dalam bentuk penginstal dan pembaruan,
- sumber daya apa yang disediakan untuk setiap tahap produksi produk,
- layanan apa yang terlibat pada setiap tahap,
- bagaimana bidang tanggung jawab untuk setiap tahap dibatasi,
- kontrak apa yang ada di pintu masuk dan keluar dari setiap tahap.
Mengklik gambar akan membukanya dalam ukuran penuh.
Pekerjaan kami di perusahaan dibagi menjadi beberapa area fungsional. Arah infrastruktur terlibat dalam optimalisasi pengoperasian semua sumber daya "besi" departemen, serta otomatisasi penerapan mesin virtual dan lingkungan di atasnya. Arah pemantauan memberikan kontrol kinerja 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 mendapatkan analitik pada proyek. Dan terakhir, arahan webdev menyediakan publikasi rilis di server pembaruan GUS dan FLUS, serta lisensi produk yang menggunakan layanan LicenseLab. Untuk mendukung alur produksi, kami menyiapkan dan mengelola berbagai layanan dukungan untuk developer (Anda dapat mendengarkan cerita tentang beberapa di antaranya di pertemuan lama: и). Kami juga mengembangkan alat otomasi internal, termasuk .
Selama lima tahun terakhir, pekerjaan kami telah mengumpulkan banyak jenis dan operasi rutin yang sama, dan pengembang kami dari departemen lain terutama berasal dari apa yang disebut tugas-tugas khas, solusi yang sepenuhnya atau sebagian otomatis, tidak menyebabkan kesulitan bagi pemain dan tidak memerlukan banyak pekerjaan. Bersama dengan bidang terkemuka, kami menganalisis tugas-tugas tersebut dan dapat mengidentifikasi kategori pekerjaan individu, atau langkah produksi, tahapan dibagi menjadi langkah-langkah yang tidak terpisahkan, dan beberapa tahapan dijumlahkan rangkaian proses produksi.
Contoh paling sederhana dari rantai teknologi adalah tahapan perakitan, penerapan, dan pengujian setiap produk kami di dalam perusahaan. Pada gilirannya, misalnya, tahap build terdiri dari banyak langkah tipikal yang terpisah: mengunduh sumber dari GitLab, menyiapkan dependensi dan pustaka pihak ketiga, pengujian unit dan analisis kode statis, menjalankan skrip build di GitLab CI, menerbitkan artefak di repositori di Artifactory dan pembuatan catatan rilis melalui alat ChangelogBuilder internal kami.
Anda dapat membaca tentang tugas khas DevOps di artikel kami yang lain di Habré: ""Dan"'.
Banyak rantai produksi tipikal terbentuk proses manufaktur. Pendekatan standar untuk mendeskripsikan proses adalah dengan menggunakan model fungsional IDEF0.
Contoh pemodelan proses manufaktur CI
Kami memberikan perhatian khusus pada pengembangan proyek standar untuk sistem integrasi berkelanjutan. Ini memungkinkan untuk mencapai penyatuan proyek, menyoroti apa yang disebut rilis skema build dengan promosi.
Begini cara kerjanya. Semua proyek terlihat tipikal: mereka menyertakan konfigurasi rakitan yang termasuk dalam repositori snapshot di Artifactory, setelah itu mereka diterapkan dan diuji di bangku pengujian, lalu dipromosikan ke repositori rilis. Layanan Artifactory adalah titik distribusi tunggal untuk semua artefak build antara tim dan layanan lainnya.
Jika kami sangat menyederhanakan dan menggeneralisasi skema rilis kami, maka itu mencakup langkah-langkah berikut:
- perakitan produk lintas platform,
- menyebarkan ke bangku tes,
- menjalankan tes fungsional dan lainnya,
- mempromosikan build yang teruji untuk merilis repositori di Artifactory,
- publikasi rilis dibuat di server pembaruan,
- pengiriman rakitan dan pembaruan untuk produksi,
- meluncurkan penginstalan dan pembaruan produk.
Misalnya, perhatikan model teknologi skema rilis tipikal ini (selanjutnya disebut Model) dalam bentuk model IDEF0 fungsional. Ini mencerminkan tahapan utama dari 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 aturan dan persyaratan apa yang harus dilakukan, apa outputnya, dan mekanisme, layanan, atau orang apa yang menerapkan tahap tertentu.
Mengklik gambar akan membukanya dalam ukuran penuh.
Sebagai aturan, lebih mudah untuk menguraikan dan merinci deskripsi proses dalam model fungsional. Tetapi ketika jumlah elemen bertambah, menjadi semakin sulit untuk memahami sesuatu di dalamnya. Namun dalam pengembangan nyata juga terdapat tahapan tambahan: pemantauan, sertifikasi produk, otomatisasi proses kerja, dan lain-lain. Karena masalah penskalaan itulah kami mengabaikan deskripsi ini.
Kelahiran harapan
Dalam satu buku, kami menemukan peta Soviet kuno yang menggambarkan proses teknologi (yang, omong-omong, masih digunakan sampai sekarang di banyak perusahaan dan universitas milik negara). Tunggu, tunggu, karena kami juga memiliki alur kerja!.. Ada tahapan, hasil, metrik, persyaratan, indikator, dan sebagainya… Mengapa tidak mencoba menerapkan flowsheet ke alur produk kami juga? Ada perasaan: “Ini dia! Kami telah menemukan utas yang tepat, saatnya menariknya dengan baik!
Dalam tabel sederhana, kami memutuskan untuk mencatat produk berdasarkan kolom, dan tahapan teknologi serta alur produk langkah demi baris. Milestone adalah sesuatu yang besar, seperti langkah pembuatan produk. Dan langkah-langkahnya adalah sesuatu yang lebih kecil dan lebih detail, seperti langkah mengunduh kode sumber ke server build atau langkah menyusun kode.
Di persimpangan baris dan kolom peta, kami meletakkan status untuk tahapan dan produk tertentu. Untuk status, satu set status ditentukan:
- Tidak ada informasi - atau tidak pantas. Untuk itu perlu dilakukan analisis permintaan terhadap suatu tahapan dalam produk. Entah analisis sudah dilakukan, tetapi tahapannya saat ini tidak diperlukan atau tidak ekonomis.
- Ditunda - atau tidak relevan saat ini. Tahapan dalam pipa diperlukan, tetapi tidak ada kekuatan untuk implementasi tahun ini.
- Berencana. Tahapan tersebut rencananya akan dilaksanakan tahun ini.
- Diimplementasikan. Tahap dalam pipa diimplementasikan dalam volume yang dibutuhkan.
Pengisian tabel dimulai proyek demi proyek. Pertama, tahapan dan langkah-langkah dari satu proyek diklasifikasikan dan dicatat statusnya. Kemudian mereka mengambil proyek berikutnya, memperbaiki status di dalamnya dan menambahkan tahapan dan langkah yang hilang pada proyek sebelumnya. Hasilnya, kami mendapatkan tahapan dan langkah dari seluruh jalur produksi kami dan statusnya dalam proyek tertentu. Ternyata sesuatu yang mirip dengan matriks kompetensi pipa produk. Kami menyebut matriks seperti itu sebagai peta teknologi.
Dengan bantuan peta teknologi, kami secara metrologis secara wajar mengoordinasikan rencana kerja untuk tahun ini dengan tim dan target yang ingin kami capai bersama: tahapan mana yang kami tambahkan ke proyek tahun ini, dan mana yang akan kami tinggalkan nanti. Selain itu, dalam perjalanan kerja, kami mungkin mengalami peningkatan pada tahapan yang telah kami selesaikan hanya untuk satu produk. Kemudian kami memperluas peta kami dan memperkenalkan peningkatan ini sebagai tahapan atau langkah baru, kemudian kami menganalisis untuk setiap produk dan mencari tahu kelayakan untuk mereplikasi peningkatan tersebut.
Mereka mungkin keberatan dengan kita: “Ini semua, tentu saja, bagus, hanya seiring berjalannya waktu jumlah langkah dan tahapan akan menjadi sangat besar. Bagaimana menjadi?
Kami telah memperkenalkan deskripsi persyaratan yang standar dan cukup lengkap untuk setiap tahap dan langkah, sehingga dipahami oleh semua orang di dalam perusahaan dengan cara yang sama. Seiring waktu, saat perbaikan diperkenalkan, satu langkah dapat diserap ke tahap atau langkah lain, dan kemudian akan "runtuh". Pada saat yang sama, semua persyaratan dan nuansa teknologi cocok dengan persyaratan tahap atau langkah generalisasi.
Bagaimana cara mengevaluasi efek replikasi solusi? Kami menggunakan pendekatan yang sangat sederhana: kami mengaitkan biaya modal awal untuk implementasi tahap baru dengan biaya produk umum tahunan, dan kemudian membaginya dengan semua saat mereplikasi.
Bagian dari pengembangan sudah ditampilkan sebagai tonggak dan langkah-langkah di peta. Kami dapat memengaruhi pengurangan biaya produk melalui pengenalan otomatisasi untuk tahapan-tahapan tertentu. Setelah itu, kami mempertimbangkan perubahan dalam karakteristik kualitatif, metrik kuantitatif, dan keuntungan yang diterima oleh tim (dalam penghematan jam kerja atau jam mesin).
Peta teknologi proses produksi
Jika kita mengambil semua tahapan dan langkah kita, menyandikannya dengan tag dan mengembangkannya menjadi satu rantai, maka itu akan menjadi sangat panjang dan tidak dapat dipahami (hanya "ekor python" 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 tahapan membangun produk [Build], menerapkannya untuk menguji server [Menyebarkan], menguji [Test], mempromosikan build untuk merilis repositori berdasarkan hasil pengujian [Promote], membuat dan menerbitkan lisensi [Lisensi], menerbitkan [ Publikasikan] di server pembaruan GUS dan pengiriman ke server pembaruan FLUS, instalasi dan pembaruan komponen produk pada infrastruktur pelanggan menggunakan Manajemen Konfigurasi Produk [Instal], serta pengumpulan telemetri [Telemetri] dari produk yang diinstal.
Selain itu, tahapan terpisah dapat dibedakan: pemantauan status infrastruktur [InfMonitoring], pembuatan versi kode sumber [SourceCodeControl], persiapan lingkungan bangun [Persiapan], manajemen proyek [Alur Kerja], menyediakan alat komunikasi kepada tim [Komunikasi], sertifikasi produk [ Sertifikasi] dan memastikan swasembada proses CI [CISelfSufficiency] (misalnya, independensi rakitan dari Internet). Lusinan langkah dalam proses kami bahkan tidak akan dipertimbangkan, karena sangat spesifik.
Akan lebih mudah untuk memahami dan melihat keseluruhan proses produksi jika disajikan dalam bentuk peta teknologi; ini adalah tabel di mana masing-masing tahap produksi dan langkah-langkah terurai dari Model ditulis dalam baris, dan dalam kolom deskripsi tentang apa yang dilakukan pada setiap tahap atau langkah. Penekanan utama ditempatkan pada sumber daya yang menyediakan setiap tahap, dan batasan area tanggung jawab.
Peta bagi kami adalah semacam pengklasifikasi. Ini mencerminkan bagian teknologi besar dari produksi produk. Berkat itu, menjadi lebih mudah bagi tim otomasi kami untuk berinteraksi dengan pengembang dan bersama-sama merencanakan penerapan tahapan otomasi, serta memahami biaya tenaga kerja dan sumber daya (manusia dan perangkat keras) yang diperlukan untuk ini.
Di dalam perusahaan kami, peta dibuat secara otomatis dari template jinja sebagai file HTML biasa, lalu diunggah ke server GitLab Pages. Tangkapan layar dengan contoh peta yang dibuat sepenuhnya dapat dilihat .
Mengklik gambar akan membukanya dalam ukuran penuh.
Singkatnya, peta teknologi adalah gambaran umum dari proses produksi, yang mencerminkan blok-blok yang diklasifikasikan dengan jelas dengan fungsionalitas yang khas.
Struktur peta jalan kami
Peta terdiri dari beberapa bagian:
- Area judul - di sini adalah gambaran umum peta, konsep dasar diperkenalkan, sumber daya utama dan hasil proses produksi ditentukan.
- Dasbor - di sini Anda dapat mengontrol tampilan data untuk masing-masing produk, ringkasan tahapan yang diterapkan dan langkah-langkah secara umum untuk semua produk disediakan.
- Peta teknologi - deskripsi tabular dari proses teknologi. Di peta:
- semua tahapan, langkah dan kodenya diberikan;
- deskripsi singkat dan lengkap tentang tahapan diberikan;
- sumber daya masukan dan layanan yang digunakan pada setiap tahap ditunjukkan;
- hasil dari setiap tahap dan langkah terpisah ditunjukkan;
- area tanggung jawab untuk setiap tahap dan langkah ditunjukkan;
- sumber daya teknis, seperti HDD (SSD), RAM, vCPU, dan jam kerja yang diperlukan untuk mendukung pekerjaan pada tahap ini, baik saat ini - sebuah fakta, dan di masa mendatang - sebuah rencana, telah ditentukan;
- untuk setiap produk, ditunjukkan tahapan atau langkah teknologi mana yang telah diterapkan, direncanakan untuk diterapkan, tidak relevan atau tidak diterapkan.
Pengambilan keputusan berdasarkan peta teknologi
Setelah memeriksa peta, beberapa tindakan dapat dilakukan - tergantung pada peran karyawan di perusahaan (manajer pengembangan, manajer produk, pengembang atau penguji):
- memahami tahapan apa yang hilang dalam produk atau proyek nyata, dan menilai kebutuhan implementasinya;
- membatasi bidang tanggung jawab antara beberapa departemen jika mereka bekerja pada tahapan yang berbeda;
- menyepakati kontrak di pintu masuk dan keluar panggung;
- mengintegrasikan tahapan pekerjaan Anda ke dalam keseluruhan proses pengembangan;
- lebih akurat menilai kebutuhan akan sumber daya yang menyediakan setiap tahapan.
Meringkas semua hal di atas
Peruteannya serbaguna, dapat diperluas, dan mudah dirawat. Jauh lebih mudah untuk mengembangkan dan memelihara deskripsi proses dalam bentuk ini daripada dalam model IDEF0 akademik yang ketat. Selain itu, deskripsi tabular lebih sederhana, lebih familiar, dan terstruktur lebih baik daripada model fungsional.
Untuk implementasi teknis langkah-langkah tersebut, kami memiliki alat internal khusus CrossBuilder - alat lapisan antara sistem CI, layanan, dan infrastruktur. Pengembang tidak perlu memotong sepedanya: dalam sistem CI kami, cukup menjalankan salah satu skrip (yang disebut tugas) dari alat CrossBuilder, yang akan menjalankannya dengan benar, dengan mempertimbangkan fitur infrastruktur kami .
Hasil
Artikel tersebut ternyata cukup panjang, tetapi hal ini tidak dapat dihindari saat menjelaskan pemodelan proses yang kompleks. Sebagai penutup, saya ingin memperbaiki secara singkat gagasan utama kami:
- Tujuan penerapan ide DevOps di perusahaan kami adalah untuk secara konsisten mengurangi biaya produksi dan pemeliharaan produk perusahaan secara kuantitatif (jam kerja atau jam mesin, vCPU, RAM, Disk).
- Cara untuk mengurangi keseluruhan biaya pengembangan adalah dengan meminimalkan biaya pelaksanaan tugas serial yang khas: tahapan dan langkah proses teknologi.
- Tugas tipikal adalah tugas yang solusinya sepenuhnya atau sebagian otomatis, tidak menimbulkan kesulitan bagi para pemain dan tidak memerlukan biaya tenaga kerja yang signifikan.
- Proses produksi terdiri dari tahapan-tahapan, tahapan-tahapan tersebut dibagi menjadi langkah-langkah yang tidak terpisahkan, yang merupakan tugas-tugas tipikal dengan skala dan ruang lingkup yang berbeda.
- Dari tugas tipikal yang berbeda, kami sampai pada rantai teknologi yang kompleks dan model multi-level dari proses produksi, yang dapat dijelaskan dengan model IDEF0 fungsional atau peta teknologi yang lebih sederhana.
- Peta teknologi adalah representasi tabular dari tahapan dan langkah-langkah proses produksi. Hal terpenting: peta memungkinkan Anda untuk melihat keseluruhan proses secara keseluruhan, dalam potongan besar dengan kemungkinan untuk merincinya.
- Berdasarkan peta teknologi, dimungkinkan untuk menilai kebutuhan untuk memperkenalkan tahapan dalam produk tertentu, menggambarkan area tanggung jawab, menyepakati kontrak pada input dan output tahapan, dan lebih akurat menilai kebutuhan akan sumber daya.
Pada artikel berikut, kami akan menjelaskan lebih detail alat teknis apa yang digunakan untuk mengimplementasikan tahapan teknologi tertentu di peta kami.
Penulis artikel:
- — Kepala Otomasi (DevOps) di Teknologi Positif
- - Wakil Kepala Departemen Otomasi (DevOps) di Teknologi Positif
Sumber: www.habr.com