¿Metodologías de desarrollo cuando cientos de desarrolladores están trabajando en una única solución?

Somos una organización que consta de alrededor de 200 desarrolladores que trabajan continuamente en un solo producto (usando el control de revisión Git) que se planea lanzar en una fecha determinada.

Debido a la gran cantidad de desarrolladores, estamos tratando de crear equipos "multifuncionales" con alrededor de 10 desarrolladores en cada equipo, lo que resulta en alrededor de 20 equipos de desarrollo en la organización.

Dado que nos gustaría mantener un "alto estándar" continuo (es decir, cuando el desarrollador hace una extracción, el producto al menos debe ser compilable, etc.) del producto en el repositorio principal, nos gustaría utilizar algún tipo de puertas de calidad.

No estoy seguro de cómo formular la pregunta, pero me pregunto si podría obtener algunos consejos sobre metodologías de desarrollo para un grupo tan grande de desarrolladores que trabajan en un solo producto.

En nuestra opinión, un extremo del espectro es permitir que cada desarrollador se comprometa directamente con el repositorio principal, sin embargo, tememos que debido al alto número de desarrolladores / compromisos que el "repositorio principal" pueda estar constantemente en una etapa interrumpida, debido no podemos tener una exigente "puerta de calidad" para cada compromiso.

El otro extremo del espectro podría ser (creemos que Linus Torvalds / Linux lo hace) un árbol o una estructura piramidal, donde el "repositorio principal" solo tiene tres fuentes de extracción, estas tres solo tienen un puñado de fuentes de extracción confiables, etc. Sin embargo, creemos que con una estructura como esa los cambios tienen una larga cadena que escalar para entrar en el "repositorio principal". Además, si se produce un conflicto de fusión, el problema recae en otro desarrollador que no sea el "desarrollador original".

Con toda esta información de fondo y opiniones, ¿cómo podemos aprender y leer las metodologías de desarrollo recomendadas para tantos desarrolladores? ¿Cómo estructuran su desarrollo las grandes organizaciones (Microsoft, Facebook, Ubuntu, etc.)?

Sin duda, debe considerar dividir el producto en módulos con equipos de interfaz que unan esos módulos constituyentes en un producto. Esto a su vez significaría dividir los repositorios para que coincidan con la partición y la jerarquía del módulo. Si parece que no puede hacer esto, entonces el proyecto probablemente se detendrá debido a la cantidad de desarrolladores que contribuyen.

Si planea usar Git para el control de versiones, le recomendaría usar un sistema de revisión de código (como Gerrit ) para mejorar la transparencia y garantizar la calidad de cada repositorio. De esa manera, todo el trabajo tendría que ser aprobado antes de fusionarse en cualquier repositorio autorizado. En este escenario, tiene sentido otorgar a ciertas personas de confianza permisos para pasar de un repositorio bajo un sistema de revisión de código a otro repositorio (también posiblemente bajo un sistema de revisión de código). Si se usa correctamente, este debería ser un proceso rápido y muy beneficioso que no obstaculice el proceso de desarrollo.

Con respecto a la verificación de compilación, necesitaría un servidor de integración continua (CI) cuyo propósito es construir y verificar automáticamente el código. Por código de verificación me refiero a que el código se compila con éxito y se pasan las pruebas. Infact Jenkins (CI Server) se puede vincular al sistema de revisión de código de Gerrit como parte de la etapa de verificación de Gerrit , automatizando completamente el proceso.

Además de estas herramientas de integración, es importante luchar por una integración frecuente como parte de la metodología de desarrollo, para minimizar la fusión de tiempo.

Puede valer la pena considerar un proceso de desarrollo ágil como Scrum cuyo propósito es dividir un producto complejo en trozos manejables de incremento de producto (llamados Sprints). Esto proporcionaría oportunidades de integración entre repositorios.

Claramente, con un equipo de desarrollo de 200 personas, debe tener algún tipo de estructura jerárquica. Un individuo o un pequeño grupo de personas está tomando decisiones sobre el diseño del producto de software. Su proceso de desarrollo debe reflejar esto: necesita revisiones de código y pruebas para asegurarse de que el software que se está creando realmente coincida con lo que desea crear (así como con fines de calidad).

Incluso los equipos pequeños necesitan líderes para guiar a los equipos y revisar su trabajo a medida que desarrollan componentes individuales. También deberían ser procesos de control de calidad a nivel de equipo.

Entonces, sí, debe seguir una estructura jerárquica con respecto al repositorio. Esto es para que coincida con la estructura jerárquica del proyecto en general.

Los componentes individuales deben construirse y probarse a un cierto nivel de adecuación antes de siquiera pensar en unirlos todos. Permitir que 200 personas se comprometan directamente con el proyecto principal sería un caos. Debería tener áreas separadas para cada grupo donde las personas pueden comprometer sus cambios en el día a día, sin afectar la construcción principal del proyecto.

Es algo muy bueno si "los cambios tienen que subir una larga cadena para entrar en el repositorio principal" porque esta cadena le permite garantizar la calidad. Puede parecer más rápido si todos los cambios se aplican inmediatamente al repositorio principal, pero de hecho, esto será un gran dolor de cabeza, ya que tendrá una compilación principal de su software constantemente defectuosa e inutilizable.

También es bueno que "si se produce un conflicto de fusión, el problema recae en otro desarrollador", específicamente, un desarrollador de nivel superior debe ser quien decida cómo resolver un conflicto.

Cuando tienes algo grande y (como consecuencia) inmanejable, la salida es dividirlo en piezas más pequeñas y manejables.

Hay varios pasos que lo ayudarán a mantener mejor al equipo y al proyecto:

1. Divide la funcionalidad en módulos. La funcionalidad debe dividirse en módulos independientes máximos utilizando los principios de inversión de alta cohesión, bajo acoplamiento y dependencia. El primer principio lo ayudará a crear módulos lógicamente consistentes. El segundo ayudará a mantener estos módulos lo más independientes posible. El tercero ayudará a desarrollar módulos dependientes simultáneamente (si el módulo A depende del módulo B, B debe proporcionar una interfaz que A pueda usar incluso cuando B no esté completamente listo).

2. Tener documentación clara. Cuando hay tantas personas trabajando juntas, las cosas pueden olvidarse o malinterpretarse fácilmente. Por lo tanto, debe prestar especial atención a toda la documentación, desde los requisitos hasta las soluciones arquitectónicas.

3. personas para tareas (nunca tareas para personas). Después de dividir la funcionalidad en conjuntos más pequeños, cree equipos para trabajar en estos conjuntos. Crear equipos será más fácil en esta etapa, porque ya sabes en qué debe trabajar cada equipo. Y tareas como las revisiones de código se realizarían dentro de cada equipo.

4. Sistema claro de tareas. Cada uno de los 200 desarrolladores debe saber claramente en qué trabajar. Esto lo ayudará a realizar un seguimiento de lo que ya se ha hecho, en qué está trabajando cada persona y cuánto trabajo le queda.

5. fuente de control. (Creo que esto se describe en otras respuestas bastante bien)))

Y finalmente, intente crear una estructura de equipos y módulos tan simple como sea posible. No puede permitirse la complejidad con un proyecto tan grande.

Además de las otras respuestas que sugieren una estructura jerárquica: eso implica que tendrá que programar puntos de 'integración' en el tiempo en los que el enfoque se centre completamente en mover el código hacia arriba en la jerarquía y 'ponerlo todo junto'. Esto no es muy diferente de los proyectos más pequeños con una fase final en la que no se realiza otro trabajo que las pruebas y la corrección de errores, solo con mayor frecuencia. Dado que está trabajando en un grupo grande que se esfuerza por alcanzar altos estándares, la mayoría de eso (estado de ánimo) probablemente ya estará en su lugar.

Además de la respuesta de hotpotato (que está directamente en la marca en mi humilde opinión), también sugeriría implementar algunas puertas de control de fuente, como usted sugiere. Cuando trasladamos un equipo grande y una base de código a git para SCM, decidimos usar lo que se llama el método del "dictador benevolente", similar al modelo que usted describió.

En este escenario, hay muchas ramas diferentes de la base de código completa que se actualizan regularmente desde su rama fuente, pero la responsabilidad de promover el código en áreas más visibles / públicas recae en una sola persona (o un pequeño grupo de personas), y generalmente es atado a un proceso de revisión de código. Con una estructura de ramificación bien organizada, esto puede funcionar REALMENTE bien. Para obtener más información, consulte este enlace .

He trabajado en un sistema enorme que tenía varios cientos de desarrolladores trabajando simultáneamente con aproximadamente 150M SLOC. Esto fue en un mainframe, por lo que no estamos hablando de Visual Studio, pero los principios aún se pueden adoptar.

En primer lugar, si está utilizando Java, definitivamente diría que use Maven. Si está usando VS, también podría usar Nuget, aunque no estoy muy seguro de si todavía está allí con Maven (también es algo diferente). El uso de un sistema como este le permitirá extraer sus dependencias y les permitirá funcionar individualmente. Tendría un script de compilación que extraiga las dependencias relevantes y compile como un lote.

Dado que no está haciendo una pregunta directamente, sino una metodología, le diré cómo lo manejó mi empleador anterior.

El sistema se dividió en grupos . Los grupos representaban áreas de negocio y áreas de infraestructura del sistema. No voy a nombrarlos, pero para un gran negocio minorista podría pensar en cosas como marketing, operaciones minoristas, operaciones en línea, compras, distribución. La infraestructura del sistema representaba cosas como clientes y seguridad. Dentro de cada grupo, había componentes . Utilizando la analogía anterior, podría considerar componentes de seguridad, por ejemplo: inicio de sesión único, servicios de directorio, auditoría, informes, etc. Cada componente tenía almacenadas sus rutinas relativas.

Como espacio de nombres o paquete, tendría Organisation.Security.DirectoryServices, por ejemplo. Al contener toda la lógica de sus áreas relevantes, los equipos trabajaron de manera bastante autónoma. Obviamente, se produjeron grandes proyectos que requerían aportes de varios equipos, pero fueron operaciones en gran medida fluidas.

Espero que esto ayude.