¿Cómo se debe almacenar el código en el control de versiones?
Desarrollador amigable ? para que ese programador pueda tomar rápidamente lo último y pueda ejecutar desde su editor sin hacer muchos cambios? (como archivos de configuración que apuntan a dev DB..etc)
o
¿Debería ser amigable con la producción ? la fuente debe ser de una manera fácil de implementar en el entorno de producción y cuando el desarrollador toma lo último, debe realizar los cambios según sus necesidades de desarrollo.
Respuestas:
Por qué elegir ? Debería ser ambos.
Su entorno de desarrollo debe configurarse para que sea tan fácil como hacer un pago, abrir, construir, ejecutar, depurar (por ejemplo: ¡no hay una ruta absoluta!). Puede hacerlo fácilmente con directivas de compilación, clase de configuración + inyección de dependencia, o incluso trucos como el perso.config en ASP.NET
Su script de compilación automatizado debe personalizarse lo suficiente como para encargarse de la configuración de producción específica, limpieza, empaquetado, etc.
Cuando se trata de un proyecto de código abierto en el que se espera que las personas contribuyan, ciertamente optaría por un desarrollador amigable.
Mi mayor disgusto por los proyectos de código abierto es que muy raramente el repositorio contiene todas las dependencias necesarias para construir el código (a veces por razones prácticas o legales), pero cuando no lo hacen, algunos ni siquiera se molestan en decirle qué dependencias necesita, o más importante, qué versión de ellos necesita. (y preferiblemente de dónde obtenerlos)
A veces puede pasar más de medio día buscando y compilando varios otros proyectos para construir el proyecto que está buscando.
Por supuesto, esto solo es relevante para el desarrollo en Windows.
Ambas, pero depende de qué tan frecuente hagas tu producción. Para muchas aplicaciones personalizadas, las implementaciones se realizan de forma manual y local. Por otro lado, el desarrollador constantemente confirmará el código, sin importar cuán pequeño o grande sea el proyecto. En mi opinión, creo que es más importante asegurarse de que el desarrollador pueda usar el control de versión correctamente, por lo tanto, hacer su vida más fácil para que tengan tiempo de enfocarse en el código en lugar de encontrar el camino a través del control de versión.
Debe ser amigable con la producción, de lo contrario es problemático mantener compilaciones automatizadas.
Estoy a favor de reducir la fricción para que sea más fácil hacer el trabajo, pero también debe tener en cuenta los modos de falla.
Si la versión del repositorio de origen siempre está configurada para uso de producción, ¿cuál es el resultado de que un desarrollador no pueda reconfigurar antes de ejecutar el sistema? Un desarrollador que ejecuta código contra producción.
Independientemente de si hay otros obstáculos en la forma en que el desarrollador realiza cambios aleatorios en la producción, construir en un modo de falla que lo aliente parece peligroso.
Sugiero que los valores predeterminados incluidos en el código comprometido siempre deben ser seguros . Compruebe los archivos de configuración de producción en el control de origen también, si lo desea, casi siempre lo hago, pero guárdelos en algún lugar "no vivo".
Tiendo a luchar por la producción amigable. Mantiene sus compilaciones limpias y evita que configuraciones extrañas entren en producción.
Definitivamente amigable para el desarrollador, con scripts para automatizar cambios para control de calidad y producción
¿Por qué no tener una rama (dependiendo del control de versión que use, yo uso Git) para el código desplegable y otro para la versión lista para desarrolladores? Esto suena mucho mejor y no es tan difícil de configurar.
Puede trabajar y confirmar sus cambios y luego combinarlos en la versión desplegable.