Este artículo es una continuación de varios artículos publicados aquí anteriormente y dedicados a las etapas:
- Declaración de requisitos
- Diseño
- Implementaciones Capa de servicio
Describe cómo organizamos el proceso de desarrollo al involucrar a los desarrolladores de la comunidad de Magento desde que el proyecto comenzó a mediados del verano pasado y con el que nos acercamos al
lanzamiento de Disponibilidad general realizado la semana pasada.
Proceso de desarrollo
Todo el trabajo en el proyecto se llevó a cabo con programadores de la comunidad de Magento, quienes se unieron al desarrollo de forma voluntaria,
tomaron tareas del
trabajo atrasado del proyecto que les resultaron interesantes y, cuando las completaron, pusieron Pull Requests en GitHub.
Como resultado, hubo más de 80 de esos tipos que hicieron al menos un grupo de solicitudes, y en total pusieron más de 800 grupos de solicitudes.
El desarrollo se realizó cara a cara en los eventos de hackathon, comúnmente llamados "Día de Contribución" en el mundo de Magento, y se distribuyó cuando los muchachos trabajaron en el proyecto de forma remota en un momento conveniente para abrir demostraciones del proyecto para mostrar resultados y hacer preguntas.
Los eventos del formato "Día de contribución", donde los programadores pueden entrar y entrar al proyecto muy fácilmente, además de discutir el problema con los arquitectos del sistema y seguir el procedimiento, la revisión del código se hizo muy popular, ya que los programadores comunitarios aprenden rápidamente y obtienen recomendaciones y consejos. de los ingenieros centrales que trabajan con el sistema, así como de adquirir habilidades sobre cómo resolver problemas típicos utilizando los mecanismos proporcionados por el marco; al mismo tiempo, realiza mejoras útiles en el sistema mismo. Como lo demuestra la práctica de Win-Win, dicho modelo se aplica a todos los participantes en el proceso, incluidas las agencias donde los programadores trabajan, participando en el proyecto como contribuyentes, porque estas agencias pueden usar el conocimiento adquirido por sus empleados como una ventaja competitiva en sus proyectos futuros.
Por ejemplo, 2 semanas antes del lanzamiento oficial, Strix, que participó activamente en la Contribución del Código para el proyecto MSI, ya había lanzado su proyecto basado en Magento 2.3 + MSI Beta, que se compartió en
su blog .
Y si hubo 15 eventos de este tipo en 2017, en 2018 hubo más de 40.
Y los eventos más numerosos reunieron a más de 100 colaboradores en un solo lugar, como el reciente Día de Contribución en Kiev antes de la conferencia # MageConf18 o el Día de Contribución de Magento Live EU en Barcelona:
Para una comunicación rápida con los desarrolladores, hemos asignado un canal Slack separado para la comunicación, que ahora consta de más de 350 desarrolladores.
Slack reemplazó cualquier mensajería instantánea, y también proporcionó herramientas para recibir rápidamente comentarios de la comunidad con productos y soluciones técnicas que íbamos a implementar. Hicimos esto con la ayuda de herramientas estándar para cuestionarios flojos.
Durante mucho tiempo, la principal fuente de documentación para el proyecto fue el
wiki del
proyecto , que incluye todos los diseños técnicos, documentación del usuario, archivos de comunicación en Slack, descripciones de las decisiones tomadas en las reuniones de preparación y stand-up.
Todos los viernes, los contribuyentes que hicieron un conjunto de solicitudes para el proyecto, así como aquellos que tienen preguntas / sugerencias sobre cómo mejorar algo, demuestran sus resultados en una manifestación de demostración abierta, a la que cualquiera puede conectarse a través de Zoom:
Y todos aquellos que no tuvieron tiempo para el rally pueden ver la grabación, ya que cada rally se registra y se presenta en
YouTube . Por ejemplo, este es un registro de la última demostración en la que el colaborador de Riccardo Tempesta demuestra el algoritmo de selección de fuente para la selección óptima de almacenes para entrega en función de las distancias entre la dirección de entrega y las direcciones de los almacenes con mercancías.
La parte más difícil en un modelo de desarrollo de software de este tipo, en el que no hay personas constantemente dedicadas al proyecto, es planificar el tiempo para la disponibilidad de accesorios y determinar la
Velocidad y capacidad de Scrum de las principales métricas para evaluar cuándo se puede entregar algún tipo de fitcha. De hecho, el contribuyente, que invirtió 20-30 horas en el proyecto dentro de una semana, no puede pasar ni una hora la próxima semana, porque en su trabajo principal habrá un bloqueo, la esposa / niña comenzará a estar celosa o en vista de cualquier otra circunstancia, porque Banal deja de ser interesante. Los desarrolladores externos no tienen, y no pueden tener ninguna obligación con el proyecto. Participan por diversión y nuevos conocimientos. ¡Y esto debemos darles sin exigir nada a cambio!
Grabe un gráfico de la implementación de Milestone 2 construida con ZenHub .En la teoría de la gestión de proyectos, generalmente intentan corregir uno de los dos indicadores Alcance fijo o Tiempo de entrega fijo, en presencia de la condición de Recursos fijos.
En el caso del modelo, cuando solo participan los desarrolladores de la comunidad, no tenemos recursos fijos y cualquier intento de arreglar el tiempo de entrega fue muy difícil.
Por lo tanto, al final, decidimos elegir y seguir el proceso de
Desarrollo basado en funciones (FDD) . Arreglando formalmente el tiempo suficiente para la iteración (hito) durante 2-3 meses. Y formar el trabajo atrasado de este hito, atraer nuevamente a la comunidad para ayudar con la priorización de tareas en este trabajo atrasado es otra característica de este modelo de desarrollo, ya que no creamos ni establecemos por sí solos las prioridades de trabajo atrasado. Los contribuyentes, especialmente si representan a empresas, a menudo se establecen su propia prioridad de ciertas tareas, que está dictada por sus proyectos actuales o futuros. Dichos contribuyentes están interesados en entregar al repositorio del proyecto principalmente lo que les interesa. Como parte del hito, trabajamos en paralelo en las historias, y podemos lanzarlas tan pronto como estemos listos, o tan pronto como llegue el momento final de la iteración. Si algunas historias no se completaron como parte de la iteración, pasan al siguiente hito.
Y lo más importante: hemos eliminado la fecha de lanzamiento del producto principal, Magento 2, ¡y ahora podemos lanzarlo independientemente! ¿Por qué seleccionamos el metapaquete del
compositor , que se refiere a todos los módulos de inventario y el enlace al metapaquete en sí desde el repositorio principal (más precisamente, desde el metapaquete del repositorio principal) se ve así:
"magento/inventory-composer-metapackage": "^1.0.3"
es decir el
carácter ^ se usa para indicar la versión del paquete.
Del mismo modo, los enlaces a todas las versiones de módulos de proyecto dentro del paquete se indican con la adición del símbolo ^:
{ "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" } }
El operador ^ existe para una compatibilidad máxima al escribir código, por lo que podemos hacer versiones internas de MSI hasta que
realicemos cambios
incompatibles con el proyecto "
> = 1.0.3 <2.0.0 ".
Por un lado, esto proporciona suficiente flexibilidad para proyectos como MSI, que comúnmente se denominan Extensiones de paquete principal de Magento (CBE). Dichos proyectos se encuentran en repositorios separados de GitHub, tienen su propia cronología de lanzamientos y están tan aislados como sea posible de otros proyectos similares y del producto principal de Magento 2. En términos de aislamiento, procesalmente, es como seguir
la Ley de Conway . Y a nivel mundial, este enfoque de desarrollo para nuevos servicios y proyectos dentro de Magento 2 corresponde al concepto de
aislamiento de servicio presentado por el consejo de arquitectura de Magento. Pero con una mayor flexibilidad viene una mayor responsabilidad (
con un gran poder viene una gran responsabilidad ), porque en este caso, dichos proyectos deben seguir estrictamente el control de versiones semántico (
SemVer ) para evitar cambios incompatibles con versiones anteriores y garantizar la facilidad de las actualizaciones para los usuarios.
El backlog del proyecto en sí, así como todas las iteraciones (incluidas las completadas) están disponibles en la página
MSI Roadmap .
Por ejemplo, este es el retraso Milestone 3, en el que recién estamos comenzando a trabajar:
Y en conclusión, me gustaría agradecer una vez más a
todos los contribuyentes que se unieron al proyecto y ayudaron a llevarlo a la etapa de lanzamiento de GA. ¡No hubiéramos tenido éxito sin ti!
