Kata Pengantar
Semuanya dimulai lebih dari 2 tahun yang lalu, dan saya beralih ke tahun ke-4 dari "Informatika Bisnis" khusus dari Universitas Negeri Tomsk Sistem Kontrol dan Radioelektronika (TUSUR). Tidak ada banyak waktu tersisa sampai akhir universitas, dan prospek untuk menulis diploma sudah membayang di depan mata kami. Ide untuk membeli karya jadi tidak dipertimbangkan. Saya benar-benar ingin melakukan sesuatu sendiri. Ada banyak opsi untuk topik proyek diploma: baik proyek konfigurasi untuk mengotomatisasi kebutuhan produksi perusahaan dan proyek untuk implementasi Manajemen Dokumen sendiri untuk 3 unit teritorial dan lebih dari 500 pengguna aktif dan pengenalan EDI. Singkatnya, banyak dari semuanya ada di kepala saya, tetapi tidak ada yang menginspirasi ini. Dan itu adalah hal utama.
Pada waktu itu saya bekerja di sebuah perusahaan terkemuka dan dalam urusan bisnis saya bertemu seorang programmer keren dan umumnya orang baik Andrei Shcheglov (Hai Andrei!) Dan entah bagaimana = selama percakapan dia bertanya kepada saya apakah saya mendengar sesuatu tentang OneScript dan Bahasa skrip Gherkin. Saya menerima jawaban yang tidak, saya tidak mendengar. Tentu saja, malam google / Yandex dan malam tanpa tidur menyebabkan gagasan bahwa ini dia - dunia yang tidak dikenal. Tetapi gagasan bahwa ini bisa menjadi subjek tesis belum muncul. Lingkaran tugas rutin adalah pekerjaan biasa dalam tugas Konfigurasi 1C, seperti yang Anda pahami dengan pengujian manual dan tidak memungkinkan Anda untuk sepenuhnya membenamkan diri dalam pendekatan baru di dunia 1C.
Konsep yang tidak dikenal
Kesulitan pertama yang saya temui adalah jumlah yang luar biasa dari berbagai terminologi dan alat yang saya belum pernah dengar sama sekali - karena pada saat itu saya adalah "odnosnik khas" (saat ini holivar dimulai ...) Terutama tidak mengetahui bahasa pemrograman lain, dan Selain itu, metodologi IT besar benar-benar asing bagi saya, saya harus melompat dari satu topik ke topik lain untuk setidaknya mengisi glosarium saya.
Hampir pada saat yang sama, saya (kami - dan kolega saya) menghadapi masalah yang agak spesifik. Mereka mengambil modul perangkat lunak dari kontraktor, memeriksa salinan. Segalanya tampak bekerja. Tetapi karena ada banyak pekerjaan, mereka menandatangani suatu tindakan pekerjaan yang selesai dan melemparkannya ke pekerjaan yang produktif. Semuanya baik selama enam bulan, sampai data dalam subsistem ini tidak melebihi yang diizinkan. Dan hal-hal yang sangat aneh mulai terjadi. Melakukan dokumen dari modul mulai terjadi selama 5-10 menit, banyak kesalahan muncul, yah, dll. Melihat kode program itu mengerikan (jangan tanya mengapa ini tidak dilakukan sebelumnya ketika menerima ...). Jumlah siklus bersarang tepat di luar yang wajar. Satu-satunya permintaan dalam siklus keempat dan banding melalui 4 poin adalah hal-hal sepele, iterasi semua dokumen sebelumnya untuk mengisi dokumen saat ini, 10 kali lipat copy-paste dari blok yang sama dan banyak lagi.
Contoh bersarang:
Duplikasi bidang dalam tata letak:
Apalagi untuk mengisi bidang-bidang ini, salinan-salinan 14 kali lipat .
Mulai dari siklus:
Dan hingga variabel FF mencapai 15:
Nah, dan banyak karya seni lain yang sama uniknya.
Tiba-tiba saya ingat bahwa untuk OneScript ada perpustakaan sederhana untuk menghitung "cyclomaticity" dari modul (1) (kompleksitas modul atau metode). Ditemukan, dihitung. Saya mendapat nilai 163 unit, dengan nilai valid tidak lebih dari 10. Dan saya sampai pada kesimpulan bahwa pengujian penerimaan kode program harus bersifat wajib dan harus otomatis dan berkelanjutan. Kemudian saya belajar tentang Pemeriksaan Berkelanjutan - dan ternyata pada tahun 2006, IBM membuat (2) publikasi tentang topik ini.
Lebih jauh lagi. Mungkin, banyak orang yang bekerja di perusahaan besar mengalami masalah dalam menyebarkan salinan pangkalan kerja pada mesin lokal pengembang. Ketika basis ini berbobot 5-10 gigabytes - ini bukan masalah, dan ketika berbobot hampir satu terabyte hanya dalam cadangan, ini sudah serius. Akibatnya, butuh waktu 5-6 jam waktu kerja untuk menggunakan salinan baru. Ketika saya bosan, saya mulai menggunakan alat yang sangat bagus 1C-Deploy-and-CopyDB (terima kasih Anton!) Lalu saya menyadari bahwa otomasi itu keren.
Selanjutnya ada tugas-tugas lain, misalnya, memperbarui basis utama dan didistribusikan secara teratur dari penyimpanan pada malam hari, pengujian formulir, pengujian skenario, dll. Beberapa dari ini disadari, tetapi beberapa tidak.
Tetapi semua ini hanya perlu bagi saya. Ketika mencari orang-orang yang berpikiran sama di kotanya, ia praktis gagal. Mereka tidak ada di sana. Meskipun sangat aneh, karena masalahnya khas. Pada saat itu saya sudah tahu bahwa saya ingin menulis tesis saya tentang topik ini. Tetapi saya tidak tahu harus menulis apa. Karena itu, saya harus bergabung dengan komunitas bukan hanya membaca, tetapi setidaknya menulis dan mengajukan pertanyaan. Tempat utama di mana Anda dapat mengajukan pertanyaan adalah
Proyek Github:
• https://github.com/silverbulleters/add
• https://github.com/oscript-library/opm
• https://github.com/EvilBeaver/OneScript
• https://github.com/silverbulleters/vanessa-runner/
Forum XDD:
• Bagian 1Script
• bagian pengujian
• bagian otomatisasi proses
Baik dan sebagai sarana komunikasi cepat - grup profil di Gitter
Koleksi material sudah dimulai. Seperti sudah ditakdirkan, saya berhasil menghubungi Alexey Lustin alexey-lustin (Hai Alexey!) Dan berbicara tentang ide diploma saya di forum XDD. Saya kaget mendengar umpan balik yang disetujui dan bahkan undangan untuk menjalani praktik pra-kelulusan di Silver Bullet. Itu sudah merupakan kemenangan. Selama beberapa jam, kami datang dengan topik dan isi diploma. Kami menetapkan tugas untuk pekerjaan praktis. Saya mendapat kepala proyek diploma dari perusahaan - Arthur Ayukhanov (Arthur hai!) Bagaimana para muda Padawan mendapat akses ke kursus video insinyur pelepasliaran dan kemampuan untuk mendapatkan Nikita Gryzlov (Hai Nikita!) Tidak terbatas dengan pertanyaannya, yang sangat ia syukuri.
Singkatnya:
Topik diploma adalah "Manajemen siklus hidup otomatis sistem informasi - rekayasa sistem dan perangkat lunak solusi pada 1C: Platform perusahaan dalam kondisi peningkatan kualitas proses proses produksi yang berkelanjutan".
Tujuan pekerjaan kualifikasi akhir (WRC) adalah untuk mengidentifikasi hubungan alat perangkat lunak dan deskripsi proses bisnis dari sirkuit DevOps di area 1C.
Pembenaran teoretis dari proyek ini adalah standar untuk peningkatan berkelanjutan kualitas layanan dari ITIL 3.0, dan objek praktisnya adalah pembangunan loop integrasi berkelanjutan untuk solusi aplikasi baru yang kami kembangkan - akun pribadi pelanggan. Untuk melakukan ini, server sumber GitLab dan loop build Jenkins dikerahkan. Pengujian dijalankan pada server khusus (Windows Slave). Konfigurasi diturunkan dari repositori 1C menggunakan pustaka Gitsync , versi 3.0
(saat ini terletak di cabang berkembang) sudah dengan prestasi Alexei Khorev (Lech halo!) dengan frekuensi 30 menit di cabang berkembang. Alasan memilih versi khusus ini adalah kemampuan untuk terhubung ke repositori melalui protokol tcp, yang, sayangnya, tidak mendukung GitSync 2.x pada saat itu. Jika perubahan dicatat di GitLab, proses loop integrasi kontinu dimulai secara otomatis.
Karena anggaran seluruh acara adalah nol, dan kemampuan untuk membangun kontrol kualitas penuh kode program tanpa membeli modul untuk SonarQube tidak mungkin, pemeriksaan sintaksis 1C standar digunakan sebagai solusi yang disederhanakan. Meskipun satu kali pembongkaran tetap dilakukan, hasilnya diperoleh dan dianalisis. Pemeriksaan tambahan untuk siklus dan adanya kode yang dapat digunakan kembali juga digunakan.
Pada tahap pengujian fungsionalitas, 2 kerangka kerja Vanessa-Behavior dan XUnitFor1C digunakan dalam versi gabungan mereka yang disebut Pengembangan Automasi Driven Vanessa (Vanessa ADD). Yang pertama digunakan untuk mulai menguji perilaku yang diharapkan, yang kedua adalah memeriksa pembukaan formulir (pengujian asap). Melewati loop integrasi berkelanjutan menghasilkan laporan yang dihasilkan secara otomatis.
Menurut hasil pengujian, insinyur rilis membuat keputusan untuk menggabungkan cabang-cabang yang mengembangkan dan menguasai, dan meluncurkan (sudah secara manual) tugas ketiga - publikasi perubahan pada basis data yang produktif. Basis data produktif tidak terhubung ke repositori dan sepenuhnya ditutup dari perubahan manual. Pembaruan hanya dilakukan melalui pengiriman, dan dalam mode otomatis.
Untuk menggambarkan proses bisnis sirkuit, diagram IDEF0 dibentuk yang terdiri dari 4 blok berturut-turut yang membentuk bagian dari sirkuit. Kesalahan yang terjadi ketika melewati salah satu tahap mengganggu proses perakitan dengan pemberitahuan ke insinyur rilis dan mentransfer kontrol ke blok 5 proses perakitan, di mana laporan dihasilkan dalam format ALLURE, JUNIT dan, tentu saja, cucumber.json.
Deskripsi Model IDEF0
Proses "Membongkar kode sumber di GIT"
Input data: - Repositori konfigurasi
Output (Keluaran): - Kode sumber
Kontrol: Petunjuk untuk bekerja dengan perangkat lunak, skrip perakitan
Mekanisme: 1C: Perusahaan, Gitsync .
Prasyarat untuk keberadaan kontur adalah keberadaan file sumber. Dari platform versi 8.3.6, 1C memberikan kemampuan untuk mengunggah kode sumber konfigurasi ke file. Perlu dicatat bahwa proses ini dapat memiliki beberapa opsi, tergantung pada spesifikasi pengembangan di departemen TI. Dalam versi saat ini, untuk menyederhanakan proses transisi karyawan ke metodologi baru, integrasi dengan proses pengembangan saat ini melalui repositori konfigurasi dan menggunakan konfigurator 1C dilakukan.
Pada tahap proses "Bongkar sumber di GIT", file, basis informasi layanan 1C akan dibuat; itu terhubung ke toko konfigurasi di bawah akun layanan; semua perubahan diterima pada saat saat ini (atau komit terakhir dalam repositori); kode sumber diturunkan ke direktori assembly; berkomitmen untuk sistem penyimpanan versi GIT; perubahan dikirim ke server sumber GitLab
Proses "menguji kualitas kode sumber"
Input data: - Kode sumber
Output (Keluaran): - Kode sumber
Kontrol: Petunjuk untuk bekerja dengan perangkat lunak, skrip perakitan
Mekanisme: 1C: Perusahaan, Deployka , SonarQube , Cyclo.os - (sayangnya tidak ada tautan)
Pada awal proses ini, kode sumber disimpan dalam repositori GitLab. Menggunakan skrip kontrol (perakitan), itu diterima di direktori perakitan. Melalui 1C: platform Perusahaan, berdasarkan pada kode sumber ini, basis informasi layanan digunakan. Analisis kesalahan dilakukan menggunakan alat platform. Jika selama analisis kesalahan kode program terdeteksi yang tidak memungkinkan untuk merakit konfigurasi, proses akan terganggu. Tujuan dari langkah ini adalah untuk menghilangkan waktu yang terbuang menganalisis kode program dari konfigurasi yang tidak beroperasi.
Setelah memeriksa kesalahan, perhitungan kompleksitas cyclomatic dari kode program dimulai. Peningkatan koefisien ini secara signifikan mempengaruhi debugging dan analisis kode program. Nilai maksimum yang diperbolehkan adalah 10. Jika terlampaui, pengecualian dilemparkan dan kode dikembalikan untuk revisi.
Langkah terakhir dalam menganalisis kualitas kode program adalah memeriksa kepatuhan terhadap standar pengembangan. Untuk tujuan ini, skema yang diusulkan menggunakan layanan SonarQube dan modul dukungan sintaks 1C yang dikembangkan olehnya dari Silver Bullet. Berdasarkan hasil analisis, sistem menghitung nilai utang teknis untuk setiap karyawan yang memposting kode program.
Proses Pengujian Fungsional
Input data: - Kode sumber
Output (Keluaran): - Kode sumber
Kontrol: Petunjuk untuk bekerja dengan perangkat lunak, skrip perakitan
Mekanisme: 1C: Perusahaan, Vanessa-Behavior, XunitFor1C .
Selama proses pengembangan, situasi dapat terjadi sehingga fungsionalitas baru dapat mengganggu operasi subsistem yang ada. Ini dapat dimanifestasikan baik dalam pembentukan pengecualian, dan kesimpulan dari hasil yang tidak diharapkan. Untuk tujuan ini, perilaku yang diharapkan dari sistem diuji.
Beberapa metode pengembangan dan pengujian berlaku untuk sirkuit ini: TDD (Test Driven Development) dan BDD (Behavior Driven Development)
Pada saat penulisan WRC, kerangka kerja Vanessa-bahavior digunakan untuk melakukan tes menggunakan Metodologi BDD, dan XunitFor1C untuk TDD. Mereka saat ini digabung dalam satu produk Vanessa-ADD. Dukungan pengembang untuk produk yang lebih lama telah dihentikan. Hasil tes adalah output ke file laporan Yandex Allure dan Xunit.
Memproses “Majelis Pengiriman”
Input data: - Kode sumber
Output data: - Pengiriman konfigurasi
Kontrol: Petunjuk untuk bekerja dengan perangkat lunak, skrip perakitan
Mekanisme: 1C: Perusahaan, pak .
Dalam proses ini, pengiriman akhir dari pengiriman konfigurasi untuk penyebaran ke sistem target terjadi. Kode sumber yang terverifikasi ada di cabang berkembang dari repositori kode sumber GitLab. Untuk membentuk pengiriman, perlu bahwa perubahan dari cabang berkembang muncul di cabang utama . Tindakan ini dapat terjadi baik secara manual dan otomatis dan diatur oleh persyaratan departemen TI menggunakan loop CI / CD. Setelah menggabungkan cabang, proses perakitan pengiriman selesai dimulai. Untuk melakukan ini, sekali lagi, di direktori perakitan, berdasarkan sumber yang ada, basis informasi layanan dibuat, dan kemudian, menggunakan alat dari 1C: platform Perusahaan, pengiriman konfigurasi dihasilkan dan diarsipkan. Pengiriman konfigurasi adalah produk akhir dari proses perakitan dan dikirimkan ke pelanggan melalui saluran komunikasi yang sudah ada atau dipasang langsung ke sistem informasi yang produktif.
Publikasikan Proses Hasil
Input data: - Bongkar hasil, laporkan file
Output data: - Laporan
Kontrol: Petunjuk untuk bekerja dengan perangkat lunak, skrip perakitan
Mekanisme: Yandex Allure , Xunit .
Saat melakukan langkah-langkah proses, alat pengujian membuat file laporan dalam format tertentu sebagai produk sampingan. Tugas dari proses ini adalah untuk mengelompokkan, mengubah dan mempublikasikan untuk kenyamanan analisis data. Jika ada pengecualian yang dihasilkan pada tahap perakitan dan dengan pengaturan yang diperlukan, sistem akan secara otomatis memberi tahu administrator loop masalah. Tahap ini dilakukan dalam proses pasca-proses perakitan dan harus dilakukan terlepas dari hasil proses sebelumnya.
Untuk umpan balik, selain mailing list, integrasi dengan Slack corporate manager digunakan, di mana semua pesan informasi dikirim mengenai status build, penampilan komit baru, pembentukan cadangan, serta pemantauan fungsi layanan yang terkait dengan sirkuit DevOps dan dari 1C hingga utuh
Hasil proyek saya adalah perlindungan WRC pada akhir Mei tahun ini dengan hasil "sangat baik". Selain itu, informasi metodologis tentang pembentukan kontur telah diperbarui.
Kesimpulan umum:
- Efek ekonomi hanya mungkin dalam jangka panjang. Dari pengalaman, tercatat bahwa ketika proyek penerapan praktik-praktik teknik diluncurkan, penurunan produktivitas pengembangan sebesar 20-30% dari level saat ini dicatat. Periode ini bersifat sementara, dan sebagai aturan, kinerja kembali ke nilai awalnya setelah tiga hingga empat bulan beroperasi. Penurunan kinerja ini terutama disebabkan oleh kenyataan bahwa pengembang harus terbiasa dengan persyaratan pengembangan baru: menulis skrip, tes, dan membuat dokumentasi teknis.
- Stabilitas sistem informasi yang produktif telah meningkat secara signifikan karena pengujian kode program. Operasi yang dijamin dari subsistem kritis disediakan oleh cakupan uji skenario. Karena itu, risiko perusahaan di daerah kritis - interaksi operasional dengan pelanggan berkurang.
- Pengecualian perbaikan dinamis pada basis informasi yang produktif memungkinkan untuk merencanakan pengembangan secara lebih konstruktif dan untuk mencegah kode perangkat lunak dari putaran pengujian.
- Mengurangi biaya tenaga kerja untuk melayani basis informasi karena otomatisasi rangkaian perakitan.
- Penggunaan umpan balik melalui Slack memungkinkan untuk memantau dan memperbaiki masalah siklus hidup sistem secara online. Menurut ulasan tim, menggunakan kurir lebih nyaman daripada mengirim surat (meskipun juga ada).
- Menggunakan inspeksi kode berkesinambungan otomatis (Continuous Inspection) untuk kepatuhan dengan standar pengembangan (SonarQube) memaksa pengembang untuk secara independen meningkatkan kompetensi mereka, dan memperbaiki utang teknis yang diidentifikasi secara langsung selama pengembangan modul perangkat lunak jauh lebih cepat, karena Anda tidak perlu menghabiskan waktu untuk memulihkan konteks tugas.
- Mengaktifkan fungsi dokumentasi otomatis dan pembuatan instruksi video dapat mengurangi jumlah permintaan pengguna.
- Selama berlangsungnya proyek, proses bisnis dibentuk yang menggambarkan siklus hidup pengembangan dan pengujian solusi aplikasi 1C, yang pada gilirannya memengaruhi pembentukan proyek untuk penerapan praktik-praktik teknik . , 1.
, . 90% .
, :
- , " 1. - , , ( 5 ).
- “ 1”. . ( , " ". ).
- CICD 1 , 5.5.0 .
, , 1 , DevOps. , — DevOps 1 .
, DevOps 1. ?