You are currently browsing the tag archive for the ‘SCM’ tag.

En el siguiente post de Henrik Kniberg comenta como llevar a la práctica los conceptos tratados en los posts sobre Software Configuration Management y Agile Software Development.

El siguiente gráfico, del mismo post, resume todo lo tratado en el artículo:

gitScrum

A continuación sencillos comentarios interesantes que aparecen en el post:

  • Cada branch (rama), incluso la mainline (tronco), tiene un owner (propietario) y una policy (política).
  • Tenemos to do, in progress y done como estados para cada user story.
  • Done (hecho) significa releasable (entregable), es decir, que si en ese momento el cliente quisiera entrar y empezar a probarlo, nadie tuviera que decirle que no puede, que tiene que esperar.
  • El tronco es la rama hecho, es decir, la que entrará en producción llegado el momento.
  • La política del tronco puede ser o (exclusivo) entregable at any time (en cualquier momento) o lo antes posible (asap).
  • Crear ramas cuantas menos mejor. Solo crearemos una cuando queramos probar algo y no lo podamos hacer con ninguna de las existentes sin violar sus políticas.
  • Como entegrable incluye las pruebas de integración y no podemos hacerlo sobre la mainline, necesitamos una nueva rama: work branch (rama de trabajo) o development branch (rama de desarrollo).
Anuncios

Seguimos con SCM, con el libro Software Configuration Management Patterns: Effective Teamwork, Practical Integration, desde donde lo dejamos en el último post sobre el tema.

Private Workspace

¿Cómo lo hacemos, con una codeline que cambia contínuamente, para realizar progresos sin que nos distraiga este entorno cambiante debido a los que están por debajo de nosotros?

Realiza tu trabajo en un workspace privado donde controlemos las versiones del código y los componentes que estamos utilizando. Debemos tener control total sobre cuando y como cambia nuestro entorno.

Repository

¿Cómo obtener las versiones correctas de los componentes correctos en un nuevo workspace?

Private System Build

¿Cómo verificas que tus cambios no rompen la construcción o el sistema antes de colocarselos?

Antes de hacer un submit al control de fuente, construir el sistema de manera privada de manera similar a como será.

SCM_psb

Integration Build

¿Cómo asegurarse de que el código base siempre se construye de manera fiable?

Asegurate de que todos los cambios (y sus dependencias) se construyen utilizando un proceso para la construcción de la integración centralizado.

SCM_ib

Third Party Codeline

¿Cúal es la estrategia mas efectiva para coordinar las versiones de vendedores de código con las versiones de productores de código?

SCM_tpc

Task Level Commit

¿Cuanto trabajo debemos realizar entre submits al sistema de control de versiones? ¿Cuando tiempo deberíamos esperar antes de colocarlos?

Realizar un commit por cada pequeña tarea de grano fino consistente.

Codeline Policy

¿Como saben los desarrolladores en que codeline deben comprobar su código y que tests deben realizar antes de hacerlo?

Para cada rama o codeline define una política que determine cómo y cúando los desarrolladores realizarán cambios. La política debe ser concisa y auditable.

Smoke Test

¿Cómo saber que el sistema seguirá funcionando después de que realizemos un cambio?

Somete cada construcción a una prueba de humo que verifique que la aplicación no se rompe de una manera evidente.

Unit Test

¿Cómo comprobar si un módulo continua funcionando tras realizar un cambio?

Desarrolla y realiza pruebas unitarias.

Regression Test

¿Cómo asegurarse de que el código existente no empeora con las nuevas mejoras?

Ejecutar pruebas de regresión en el sistema siempre que lo desee para asegurar la estabilidad de la codeline, como antes de liberar una construcción, o antes de un cambio especialmente arriesgado.
Crea las pruebas de regresión a partir de los casos de prueba que hicieron fallar al sistema en el pasado.

Private Versions

¿Cómo puedes experimentar con un cambio complejo y beneficiarse del sistema de control de versiones sin hacer el cambio público?

Provee a los desarrolladores de un mecanismo de checkpoints de cambios en una granularidad que se sienta cómodo. Esto puede hacerse mediante un área de control para versiones locales. Sólo los conjuntos de código estables se registrarán en el repositorio del proyecto.

Release Line

¿Cómo mantener versiones publicadas sin interferir en el trabajo actual de desarrollo?

SCM_rl

Release-Prep Codeline

¿Cómo se puede estabilizar una codeline para un lanzamiento inminente, además de facilitar el continuar trabajando en la codeline activa?

SCM_rpc

Task Branch

¿Cómo puede nuestro equimo hacer a una codeline múltiples cambios a largo plazo superpuestos sin comprometer su consistencia e integridad?

SCM_tb

Acabo de conseguir el libro Software Configuration Management Patterns: Effective Teamwork, Practical Integration de Stephen P. Berczuk, Brad Appleton y Kyle Brown en el que se abordan diferentes patrones para la Gestión de Configuración de Software. Además, encontre una presentación de G. Serrano basada en el libro que cubre sobradamente nuestros intereses.

En la práctica, la SCM se preocupa de como construir y lanzar un producto, así como de la identificación y el seguimiento de sus modificaciones.

Para empezar, ¿qué entendemos por patrón? La idea de patrón tal y como la utilizaremos aparece originalmente en el trabajo que el arquitecto Christopher Alexander hizo en construcción arquitectónica para describir las cualidades de un buen diseño arquitectónico. Define patrón como una “solución a un problema en un contexto”, como algo que “describe un problema que ocurre una y otra vez en nuestro entorno, y describe la esencia de la solución a dicho problema, de manera que puedes utilizar esa solución millones de veces sin tenerlo que hacer dos veces de la misma manera”.

El esquema de patrones que seguiremos es:

SCMPatternLanguage

diciembre 2017
L M X J V S D
« Ago    
 123
45678910
11121314151617
18192021222324
25262728293031