ACTUALIZACIÓN
Trabajo en un pequeño equipo de desarrolladores, 4 chicos. Todos ellos han usado control de fuente. La mayoría de ellos no pueden soportar el control de la fuente y en su lugar optan por no usarlo. Creo firmemente que el control de la fuente es una parte necesaria del desarrollo profesional. Varios problemas hacen que sea muy difícil convencerlos de usar el control de código fuente:
- El equipo no está acostumbrado a usar TFS . He tenido 2 sesiones de entrenamiento, pero solo se me asignó 1 hora, lo cual es insuficiente.
- Los miembros del equipo modifican directamente el código en el servidor. Esto mantiene el código fuera de sincronización. Requerir comparación para estar seguro de que está trabajando con el último código. Y surgen problemas complejos de fusión
- Las estimaciones de tiempo ofrecidas por los desarrolladores excluyen el tiempo requerido para solucionar cualquiera de estos problemas. Entonces, si digo que no, tardará 10 veces más ... Tengo que explicar constantemente estos problemas y arriesgarme a mí mismo porque ahora la administración puede percibirme como "lento".
- Los archivos físicos en el servidor difieren en formas desconocidas sobre ~ 100 archivos. La fusión requiere el conocimiento del proyecto en cuestión y, por lo tanto, la cooperación del desarrollador que no puedo obtener.
- Otros proyectos se están desincronizando. Los desarrolladores siguen desconfiando del control de origen y, por lo tanto, complican el problema al no usar el control de origen.
- Los desarrolladores argumentan que usar el control de código fuente es un desperdicio porque la fusión es propensa a errores y es difícil. Este es un punto difícil de argumentar, porque cuando el control de la fuente se está utilizando de manera tan incorrecta y el control de la fuente se pasa por alto continuamente, de hecho es propenso a los errores. Por lo tanto, la evidencia "habla por sí misma" en su opinión.
- Los desarrolladores argumentan que la modificación directa del código del servidor, al omitir TFS ahorra tiempo. Esto también es difícil de discutir. Debido a que la combinación requerida para sincronizar el código para comenzar requiere mucho tiempo. Multiplica esto por los más de 10 proyectos que manejamos.
- Los archivos permanentes a menudo se almacenan en el mismo directorio que el proyecto web. Así que la publicación (publicación completa) borra estos archivos que no están en el control de código fuente. Esto también genera desconfianza en el control de la fuente. Porque "la publicación rompe el proyecto". Arreglar esto (mover archivos almacenados de las subcarpetas de la solución) requiere mucho tiempo y depuración, ya que estas ubicaciones no se configuran en web.config y suelen existir en múltiples puntos de código.
Entonces, la cultura persiste. La mala práctica engendra más mala práctica. Las malas soluciones impulsan nuevos hacks para "arreglar" problemas mucho más profundos y que consumen mucho más tiempo. Los servidores, el espacio en el disco duro son extremadamente difíciles de conseguir. Sin embargo, las expectativas de los usuarios están aumentando.
¿Qué se puede hacer en esta situación?