¿Qué guías o estándares usas para el control de versiones en tu equipo?

Estoy comenzando a hacer una pequeña cantidad de desarrollo dentro de mi compañía. Tengo la intención de usar Git para el control de versiones, y me interesa ver qué directrices o normas usan las personas en torno a la versión en sus grupos, similar a los estándares de encoding que a menudo se escriben dentro del grupo para el grupo.

Supongo que habrá cosas como;

  • Comprometerse a menudo (al less todos los días / semanas / reuniones, etc.)
  • Las versiones de lanzamiento siempre se hacen desde la twig principal
  • Antes del lanzamiento, se creará una nueva twig para Pruebas y se labelrá como tal. solo correcciones de errores a partir de este punto en adelante. La versión final de este se labelrá como tal y las correcciones de errores se fusionaron de nuevo en el tronco
  • Cada desarrollador tendrá un repository público
  • Las nuevas características deberían tener su propia twig

Obviamente, mucho de esto dependerá de qué VCS esté usando y cómo lo haya estructurado.

Preguntas similares;
git branch nombrando las mejores prácticas
¿Existe una convención de nomenclatura estándar para las tags git?

En el lugar actual donde trabajo, el sistema de control de versiones es uno de los más avanzados y maduros. Así es como lo hacemos.

Tenemos algo llamado como una twig "principal" que es la base de código que estará en producción. Tenga en count que el código base en una sola estructura colosal enorme. Digamos que si llega un nuevo proyecto, tendremos que searchlo y reservaremos una semana de lanzamiento. Ahora tenemos que empezar a trabajar en eso. Entonces, cortamos una twig de la principal llamada como una twig de característica. El equipo o el grupo de desarrolladores siguen trabajando en esa twig de características en particular. Tenga en count que habrá una gran cantidad de cortes de twigs de funciones simultáneamente desde la twig principal.

Ahora, una vez que se termina el desarrollo, se acostumbra fusionar el código nuevamente en main. No lo haremos directamente, ya que podría causar esgulps debido a problemas obvios de criticidad. Entonces, tenemos una twig más de la principal llamada prelanzamiento. Fusionamos todo nuestro código a esa base de lanzamiento. Y hacer una compilation en la base de código completo. La construcción debería pasar. Cuando lo hace, extraemos una timestamp verde (última versión pasada). Una vez que se obtiene la timestamp verde, el código se fusionará de la twig previa a la versión principal y la versión finalizada.

Una vez que el código se pone en producción y decir si enfrentamos algunos errores, cortamos una twig de la principal llamada como una twig de corrección de errores. Haz todos los cambios. Y fusionarlo nuevamente a main; siempre sigue el process de sello de time pre-lanzamiento / verde. Es inevitable.

Re-base. Ok, al principio dije que hubiéramos reservado cuando nuestra function de twig deba completarse. Durante este período de time, habrá mucha actualización de código que haya sucedido en main. Por lo tanto, es prácticamente necesario que continúe actualizando su twig de funciones actual para estar sincronizado con main. Para eso, se realiza un process llamado como rebase. Es como get el último código de main para que no estés trabajando en una twig que está desactualizada. En mi organización actual, se iniciará una rebase cada 2-3 semanas, aunque las políticas recomiendan 1 semana.

Características más interesantes: digamos que actualmente estoy trabajando en una twig llamada Feature y quiero get algún código de uno de los otros equipos que también están trabajando en su propia twig de características (este escenario aunque parece poco común ocurre con frecuencia). Para eso vamos a cambiar nuestra config-spec (ClearCase es nuestro sistema de control de versiones), para apuntar a los files requeridos del otro proyecto. Se puede utilizar LATEST o se puede especificar TIMESTAMP para extraer los files procedentes de la otra twig de características.

Después de una buena cantidad de time después de la puesta en marcha del proyecto, la twig de características que cortamos prácticamente no es necesaria. Se puede terminar desde el sistema, por ejemplo, después de un año, el espacio debería ser una restricción.

Solo un estándar:

  1. Controlar los cambios de última hora resultará en una patada.

mi 'cvs' es TFS así que tómalo por lo que vale.

Si alguien rompe la construcción, se aplica la regla de donut (trae la caja de donut al día siguiente)

Has mencionado cometer a menudo, según el día, la semana o la reunión. ¿Este sistema no introduciría un código incompleto? Podría ser más estable confirmar después de la revisión del código.

Establecer una unit testings sería una buena práctica para empezar, ya que es como tener un segundo equipo de QA trabajando de la noche a la mañana (cuando esas testings unitarias se ejecutan como parte de la compilation de la noche a la mañana).

En cuanto a tener una sucursal por característica, no es algo que utilicé, sino algo de lo que hablamos cuando alguien rompió la construcción, ya que si un equipo rompió una function, el rest de las cosas aún se desarrolló. Para que esto funcione, su progtwig de installation debe ser lo suficientemente flexible como para comstackr y ser capaz de implementar incluso si faltan características opcionales.

Construir por características como esta puede boost la productividad ya que el control de calidad puede comenzar a probarse al día siguiente en lugar de ser bloqueado por una compilation rota hasta que se solucione más tarde o incluso retroceder solo para ver si ocurre otro problema similar.

CVS es bien conocido, pero si estuviera comenzando un equipo / proyecto de desarrollo, podría considerar echar un vistazo a Jira Studio

http://www.youtube.com/watch?v=2w2uN3c8pfA http://www.youtube.com/watch?v=c9pm_r8vSwM&feature=related

Una vez que tenga su twig principal, cualquier tarea o característica en la que desee trabajar debe desarrollarse en su propia twig. Trate de mantener la twig principal estable y de producción list en todo momento. Cuando tengas una tarea, bifurca una bifurcación, haz tu trabajo allí, soluciona cualquier error y luego vuelve a fusionar con el maestro.

No es necesario registrarse por día (ni en ninguna otra unidad de time). Siempre hacemos nuestros check-ins basados ​​en la finalización de características, no necesariamente un set completo de características, sino en pequeños fragments lógicos manejables. Esto nos permite encontrar errores más fácilmente que tener un check-in diario de todo el código, ya sea que esté relacionado o no.

Mantenga sus posts de confirmación claros y al grano, esto lo ayudará muchísimo cuando vuelva a visitar su código.

Una pequeña colección con git, cuando bifurcas una twig, se bifurca de la twig en la que te encuentras actualmente, no del maestro. Esto es algo obvio, pero siempre revise dos veces su twig actual antes de bifurcar una nueva twig.

Utilice el file .gitignore para mantener los files que no desea rastrear fuera del control de versión en lugar de saturar sus posts de estado de git o sobrescribir un file que no debería estar en control de versiones en primer lugar (configuration de DB y tal)

Solo ingrese (o promueva, dependiendo de su herramienta) código de trabajo en la twig / secuencia / depósito / repository "principal" (elija su propia definición de "principal"). Esta twig "principal" debe seguir siendo comstackble y comprobable en todo momento.