Artikel ini merupakan kelanjutan dari sejumlah artikel yang diterbitkan di sini sebelumnya dan didedikasikan untuk tahapan:
- Pernyataan persyaratan
- Desain
- Implementasi. Lapisan layanan
Ini menjelaskan bagaimana kami mengorganisasikan proses pengembangan dengan melibatkan pengembang dari komunitas Magento sejak proyek dimulai pada pertengahan musim panas lalu dan dengan mana kami mendekati
rilis Ketersediaan Umum yang dibuat minggu lalu.
Proses pengembangan
Semua pekerjaan pada proyek dilakukan dengan programmer dari komunitas Magento, yang bergabung dengan pengembangan atas dasar sukarela,
mengambil tugas dari simpanan proyek yang menarik bagi mereka dan, ketika mereka menyelesaikannya, masukkan Pull Requests pada GitHub.
Akibatnya, ada lebih dari 80 orang seperti itu yang membuat setidaknya satu kelompok permintaan, dan secara total mereka menempatkan lebih dari 800 kelompok permintaan.
Pengembangan dilakukan secara tatap muka di acara-acara hackathon, yang biasa disebut "Hari Kontribusi" di dunia Magento, dan dibagikan ketika para lelaki bekerja pada proyek tersebut dari jarak jauh pada waktu yang tepat untuk membuka demo pada proyek untuk menunjukkan hasil dan mengajukan pertanyaan.
Acara format "Hari Kontribusi", di mana pemrogram dapat datang dan memasuki proyek dengan sangat mudah, serta mendiskusikan masalah dengan arsitek sistem dan melalui prosedur, ulasan kode telah menjadi sangat populer, karena pemrogram komunitas belajar dengan cepat dan mendapatkan rekomendasi dan tips. dari insinyur inti yang bekerja dengan sistem, serta memperoleh keterampilan tentang cara menyelesaikan masalah tipikal menggunakan mekanisme yang disediakan oleh kerangka kerja; pada saat yang sama melakukan perbaikan yang bermanfaat pada sistem itu sendiri. Seperti yang ditunjukkan oleh praktik Menang-Menang dari model tersebut, ini berlaku untuk semua peserta dalam proses, termasuk agensi yang mempekerjakan programmer yang berpartisipasi dalam proyek sebagai kontributor, karena agensi ini dapat menggunakan pengetahuan yang diperoleh karyawan mereka sebagai keunggulan kompetitif dalam proyek masa depan mereka.
Sebagai contoh, 2 minggu sebelum rilis resmi, Strix, yang secara aktif berpartisipasi dalam Kontribusi Kode untuk proyek MSI, telah meluncurkan proyeknya berdasarkan Magento 2.3 + MSI Beta, yang dibagikan di
blog-nya .
Dan jika ada 15 acara seperti itu di tahun 2017, maka pada tahun 2018 ada lebih dari 40 acara.
Dan acara paling banyak mengumpulkan 100+ kontributor di satu tempat, seperti Hari Kontribusi baru-baru ini di Kiev sebelum konferensi # MageConf18 atau Hari Kontribusi EU Magento Live di Barcelona:
Untuk komunikasi cepat dengan pengembang, kami telah mengalokasikan saluran Slack terpisah untuk komunikasi, yang sekarang terdiri dari lebih dari 350 pengembang.
Slack mengganti semua pengirim pesan instan, dan juga menyediakan alat untuk dengan cepat menerima umpan balik dari masyarakat dengan produk dan solusi teknis yang baru akan kami terapkan. Kami melakukan ini dengan bantuan alat standar untuk kuesioner di kendur.
Untuk waktu yang lama, sumber utama dokumentasi untuk proyek ini adalah
proyek wiki , yang mencakup semua desain teknis, dokumentasi pengguna, arsip komunikasi di Slack, deskripsi keputusan yang dibuat di Grooming dan Stand-up unjuk rasa.
Setiap hari Jumat, kontributor yang membuat kumpulan permintaan untuk proyek, serta mereka yang memiliki pertanyaan / saran tentang cara meningkatkan sesuatu, menunjukkan hasilnya pada demo terbuka, di mana siapa pun dapat terhubung melalui Zoom:
Dan semua yang tidak punya waktu untuk reli dapat menonton rekaman, karena setiap reli tersebut direkam dan ditata di
YouTube . Misalnya, ini adalah catatan demo terakhir tempat kontributor Riccardo Tempesta menunjukkan Algoritma Pemilihan Sumber untuk pemilihan gudang yang optimal untuk pengiriman berdasarkan jarak antara alamat pengiriman dan alamat gudang dengan barang.
Hal yang paling sulit dalam model pengembangan perangkat lunak seperti itu, di mana tidak ada orang yang selalu berdedikasi pada proyek, adalah merencanakan waktu untuk ketersediaan alat kelengkapan dan menentukan
Scrum Velocity & Capacity dari metrik utama untuk menilai kapan suatu kecocokan tertentu dapat disampaikan. Bahkan, kontributor, yang menginvestasikan 20-30 jam dalam proyek dalam satu minggu, mungkin tidak menghabiskan satu jam bahkan minggu depan, karena pada pekerjaan utamanya akan ada penyumbatan, istri / gadis akan mulai cemburu atau mengingat keadaan lain, karena seseorang dapat berhenti dangkal menjadi menarik. Pengembang pihak ketiga tidak, dan tidak dapat memiliki kewajiban terhadap proyek. Mereka berpartisipasi untuk kesenangan dan pengetahuan baru. Dan ini kita harus memberi mereka tanpa menuntut imbalan apa pun!
Membakar grafik implementasi Milestone 2 yang dibangun dengan ZenHub .Dalam teori manajemen proyek, mereka biasanya mencoba memperbaiki salah satu dari dua indikator Lingkup Tetap atau Waktu Pengiriman Tetap, di hadapan kondisi Sumber Daya Tetap.
Dalam hal model, ketika hanya pengembang dari komunitas yang berpartisipasi, kami tidak memiliki Sumber Daya Tetap dan segala upaya untuk memperbaiki waktu pengiriman sangat sulit.
Oleh karena itu, pada akhirnya, kami memutuskan untuk memilih dan mengikuti proses
development-driven development (FDD) . Memperbaiki waktu yang cukup secara formal untuk iterasi (tonggak) selama 2-3 bulan. Dan membentuk backlog dari tonggak sejarah ini, sekali lagi menarik masyarakat untuk membantu memprioritaskan tugas-tugas dalam jaminan ini adalah fitur lain dari model pengembangan ini, karena kami tidak sendirian membuat dan menetapkan prioritas jaminan simpanan produk. Kontributor, terutama jika mereka mewakili perusahaan, sering menetapkan sendiri prioritas mereka untuk tugas-tugas tertentu, yang ditentukan oleh proyek mereka saat ini atau masa depan. Kontributor seperti itu tertarik untuk mengirimkan ke repositori proyek terutama yang menarik bagi mereka. Sebagai bagian dari tonggak sejarah, kami bekerja secara paralel pada cerita, dan kami dapat merilisnya segera setelah kami siap, atau segera setelah mencapai akhir waktu iterasi. Jika beberapa cerita tidak selesai sebagai bagian dari iterasi, mereka beralih ke Milestone berikutnya.
Dan yang paling penting - kami menyingkirkan tanggal rilis produk utama - Magento 2 dan sekarang kami dapat dirilis secara terpisah! Mengapa kami memilih
paket meta komposer , yang merujuk ke semua modul Inventaris dan tautan ke
paket meta itu sendiri dari repositori utama (lebih tepatnya, dari paket meta dari repositori utama) terlihat seperti ini:
"magento/inventory-composer-metapackage": "^1.0.3"
yaitu
karakter ^ digunakan untuk menunjukkan versi paket.
Demikian pula, tautan ke semua versi modul proyek di dalam paket ditandai dengan penambahan simbol ^:
{ "name": "magento/inventory-composer-metapackage", "version": "1.0.3", "description": "Metapackage with Magento Inventory modules for simple installation", "type": "metapackage", "require": { "magento/inventory-composer-installer": "^1.0.3", "magento/module-inventory": "^1.0.3", "magento/module-inventory-admin-ui": "^1.0.3", "magento/module-inventory-api": "^1.0.3", "magento/module-inventory-bundle-product": "^1.0.3", "magento/module-inventory-bundle-product-admin-ui": "^1.0.3", "magento/module-inventory-cache": "^1.0.3", "magento/module-inventory-configurable-product": "^1.0.3", "magento/module-inventory-catalog-api": "^1.0.3", "magento/module-inventory-catalog": "^1.0.3", "magento/module-inventory-catalog-admin-ui": "^1.0.3", "magento/module-inventory-catalog-search": "^1.0.3", "magento/module-inventory-configurable-product-admin-ui": "^1.0.3", "magento/module-inventory-configurable-product-indexer": "^1.0.3", "magento/module-inventory-configuration": "^1.0.3", "magento/module-inventory-configuration-api": "^1.0.3", "magento/module-inventory-grouped-product": "^1.0.3", "magento/module-inventory-grouped-product-admin-ui": "^1.0.3", "magento/module-inventory-grouped-product-indexer": "^1.0.3", "magento/module-inventory-import-export": "^1.0.3", "magento/module-inventory-indexer": "^1.0.3", "magento/module-inventory-multi-dimensional-indexer-api": "^1.0.3", "magento/module-inventory-low-quantity-notification": "^1.0.3", "magento/module-inventory-low-quantity-notification-api": "^1.0.3", "magento/module-inventory-low-quantity-notification-admin-ui": "^1.0.3", "magento/module-inventory-product-alert": "^1.0.3", "magento/module-inventory-reservations": "^1.0.3", "magento/module-inventory-reservations-api": "^1.0.3", "magento/module-inventory-sales": "^1.0.3", "magento/module-inventory-sales-admin-ui": "^1.0.3", "magento/module-inventory-sales-api": "^1.0.3", "magento/module-inventory-sales-frontend-ui": "^1.0.3", "magento/module-inventory-shipping": "^1.0.3", "magento/module-inventory-shipping-admin-ui": "^1.0.3", "magento/module-inventory-source-deduction-api": "^1.0.3", "magento/module-inventory-source-selection-api": "^1.0.3", "magento/module-inventory-source-selection": "^1.0.3" } }
Operator ^ ada untuk kompatibilitas maksimum saat menulis kode, sehingga kami dapat melakukan rilis MSI internal hingga kami membuat perubahan yang
tidak kompatibel ke belakang ke proyek "
> = 1.0.3 <2.0.0 ".
Di satu sisi, ini memberikan fleksibilitas yang cukup untuk proyek-proyek seperti MSI, yang umumnya disebut Magento Core Bundle Extensions (CBE). Proyek-proyek semacam itu terletak di repositori GitHub yang terpisah, memiliki kronologi pelepasan mereka sendiri, dan sebisa mungkin terisolasi dari proyek serupa lainnya dan dari produk Magento 2. Dalam hal isolasi, secara prosedural, seperti mengikuti
Hukum Conway . Dan secara global, pendekatan pengembangan ini untuk layanan dan proyek baru dalam Magento 2 sesuai dengan konsep
Isolasi Layanan yang disajikan oleh dewan arsitektur Magento. Tetapi dengan fleksibilitas yang lebih besar datang tanggung jawab yang lebih besar (
dengan kekuatan besar datang tanggung jawab besar ), karena dalam hal ini, proyek semacam itu harus secara ketat mengikuti semantic versioning (
SemVer ) untuk mencegah perubahan mundur yang tidak kompatibel dan untuk memastikan kemudahan peningkatan bagi pengguna.
Tumpukan proyek itu sendiri, serta semua iterasi (termasuk yang sudah selesai) tersedia di halaman
Roadmap MSI .
Sebagai contoh, ini adalah backlog Milestone 3, yang baru saja kami mulai bekerja:
Dan sebagai kesimpulan, saya ingin sekali lagi mengucapkan terima kasih kepada
semua kontributor yang bergabung dengan proyek dan membantu membawanya ke tahap rilis GA. Kami tidak akan berhasil tanpamu!
