Ideas sobre la configuration de un sistema de control de versiones

Me han encomendado la tarea de configurar un control de versión para nuestros desarrolladores web. El software, que fue elegido para mí porque ya tenemos otros desarrolladores que no lo usan, es Serena PVCS.

Me está costando mucho time tratar de decidir cómo configurarlo, así que describiré cómo ocurre el desarrollo en nuestro sistema, y ​​espero que genere cierta discusión sobre la mejor manera de hacerlo.

Tenemos 3 serveres, Desarrollo, UAT / Puesta en escena y Producción. Los desarrolladores web solo tienen acceso para escribir y probar su código en el server de Desarrollo. Una vez que escriben el código, deben pasar por un process de certificación para mover el código a UAT / Clasificación por etapas, luego, una vez que el código se ha probado exhaustivamente allí, se mueve a Producción.

Parece que hacer que los Desarrolladores utilicen el control de versiones para su código en Desarrollo, que cambian constantemente y las testings serían una molestia. Normalmente, solo un desarrollador trabaja en un module a la vez, por lo que no existe mucho riesgo de sobreescribir el trabajo de otras personas.

Mi idea era que solo utilizaran el control de versiones cuando estuvieran listos para ir a UAT / Staging. Esto les permite desarrollar y probar sin verificar constantemente su código.

El grupo de certificación podría usar el control de versiones para ayudar a ver qué cambios se habían realizado en el module y asegurarse de que siempre obtuvieran la última revisión del desarrollador para colocarla en UAT / Clasificación por etapas (ahora dependemos del desarrollador zip ' actualizar sus files modificados y uploadlos a través de un sistema de request web).

Esto se ocuparía del lado del file del desarrollo, pero deja a toda la database fuera del control de la versión. Eso es algo más que necesito considerar …

Cualquier pensamiento o idea sería muy apreciado. Gracias.

No trataría el control de fuente como una molestia. Vea la respuesta de Nicks por las razones.

Si yo fuera usted, no decidiría esto por mi count, porque no se trata de configurar un software de control de versiones en algún server, sino de cambiar y mejorar los procedimientos de desarrollo.

En su caso, podría valer la pena explicar y discutir las twigs de publicación con sus desarrolladores y con la garantía de calidad. Esto significa que tus desarrolladores deciden qué function include en un lanzamiento y mientras el equipo de puesta en escena está ocupado probando la twig de "puesta en escena" de la fuente, tus desarrolladores ya pueden trabajar en la próxima versión sin interferir con el equipo de preparación.

También puede pensar en twigs de características , lo que significa que hay una nueva twig para cada nueva característica específica del website. Esas twigs se fusionan de nuevo, si la característica se implementa.

Pero nuevamente: asegúrese de que sus equipos estén de acuerdo con el nuevo process de desarrollo. De lo contrario, pierdes tu time configurando un sistema de control de versiones.

El process debería include al less:

  • Cuándo cometer
  • Cuándo ramificar / fusionar.
  • Qué / Cuándo labelr
  • El flujo de trabajo general.

He usado Serena, y de hecho es una molestia. Además de lo desagradable de la sobrecarga del flujo de trabajo que Serena pone al tope del process de verificación de input y salida, es un verdadero dolor con respecto a hacer cualquier cosa además de las tareas más simples.

En Serena ChangeMan, todo el código de las máquinas locales se gestiona a través de un server central. Este es un layout realmente malo. Esto significa que una gran parte del trabajo diario de mantenimiento de la sucursal que normalmente realizarían los desarrolladores tiene que pasar por quien tiene privilegios de administrador, haciendo que esa persona 1) sea un cuello de botella y 2) amargado porque tienen un trabajo de chuparse el alma.

La administración centralizada también limita estrictamente lo que los desarrolladores pueden hacer con el código en su propia máquina. Por ejemplo, si desea crear una segunda copy del código localmente en su caja, solo para hacer una testing rápida o lo que sea, debe hacer que el administrador configure un segundo repository en su caja. Cuando limita a los desarrolladores de esta manera, limita la productividad y la creatividad de su equipo.

Además, las herramientas son malas y la interfaz de usuario es espantosa. Y nunca podrás encontrar desarrolladores que ya estén entrenados para usarlo, porque es demasiado oscuro.

Entonces, si otro equipo dice que tiene que usar Serena, retroceda. Ese producto es terrible.

Usar el control de fuente no es ninguna molestia, es una herramienta. Tener los beneficios de ramificación y labeldo es invaluable cuando se trabaja con nuevas API y bibliotecas.

Y solo una nota al margen, hace un par de meses, una de las máquinas del desarrollador falló y perdió toda su fuente más reciente, le preguntamos cuándo fue la última vez que él entregó el código al control de código fuente y fue de 2 meses. Algunas veces solo tenerlo para respaldar cosas cuando alcanzas hitos es bueno.

Por lo general, me comprometo a controlar la fuente un par de veces a la semana, dependiendo de si alcancé un buen punto de parada y estoy a punto de pasar a algo diferente o más grande.

Siguiendo con los dos últimos puntos buenos, también les preguntaría a los otros desarrolladores no web qué process de desarrollo están usando para que no tengan que crear uno nuevo. También se habrían encontrado con muchos de los problemas que ocurren en su entorno, tanto los técnicos que utilizan el mismo sistema operativo y la configuration y la gestión.