Subversion / control de fuente solo para el código de producción?

Me gradué de la universidad en Ciencias de la Computación hace un año, y ahora estoy trabajando en una pequeña empresa de desarrollo web (yo y otro desarrollador, más gerentes, servicio al cliente y probador). Hasta justo antes de comenzar, no había un sistema de control de fuente. Ahora estamos comenzando lentamente a implementar SVN, pero el otro desarrollador (senior) (en adelante, Joe) insiste en que el único código que debe comprometerse con nuestro repositorio SVN es el que ha sido probado y aprobado como listo para producción. Eso significa que, en proyectos más grandes, puede que no haya compromisos durante semanas a la vez o más.

¿Es esta una práctica normal? Me parece que perdemos muchos de los beneficios del control de fuente, que incluyen:

• Seguimiento detallado del progreso del proyecto.
• Seguimiento de los problemas tal como aparecen y se resuelven
• Revertir fácilmente los errores
• Fácil copia de seguridad del código, por lo que no perdemos mucho si una estación de trabajo se cae
• Es más fácil identificar exactamente qué código se está ejecutando en qué sitios de producción, suponiendo que estampamos las revisiones en ejecutables como se describe aquí
• Colaboración fácil (aunque no hacemos ningún trabajo en equipo; son todos proyectos en solitario)
• Etc.

EDITAR: Debo enfatizar que históricamente, no ha habido ningún verdadero trabajo en equipo en esta empresa; solo dos desarrolladores trabajando en proyectos separados. Además, muchos de los proyectos son pequeños, por lo que se pueden completar en un par de semanas. Y la compañía ha estado en el negocio por más de una década y se ha llevado bien sin control de fuente. Los proyectos generalmente se completan dentro de su plazo estimado.

Si los proyectos se completan dentro de su plazo estimado, ¿es seguro asumir que los clientes son clientes satisfechos? :)

Parece que la compañía está comenzando a asumir nuevos tipos de proyectos también y atravesando algunos dolores de crecimiento o algunos "dolores cambiantes". Muchas suposiciones pasando aquí ... ¡Por favor tengan paciencia conmigo!

Si está seguro de que la organización y el control del código pueden ayudarlo a usted y a su equipo internamente, entonces se debe considerar SVN, en mi humilde opinión. ¡Obtienes puntos de bonificación si seguir esta ruta realmente funciona y la compañía puede fabricar productos de mayor calidad y, por lo tanto, hacer clientes más felices!

Tenga cuidado si parece que una lucha con la administración va a crear un ambiente de trabajo tenso. El hecho es que los propietarios han hecho la empresa. Y no solo eso, han hecho una compañía exitosa. Es poco probable que ganen un premio gordo porque son buenos para apostar.

Sea respetuoso y puede terminar siendo escuchado.

Esperemos que esto termine resultando en un equipo más eficiente y más feliz. En mi experiencia, eso es difícil de obtener con una gestión frustrada.

Joe está bastante equivocado. Ahora, puede argumentar que tiene una rama "limpia" que representa el código examinado y listo para producción. Pero no usar el control de fuente hasta que las cosas estén listas es francamente contraproducente. Algo así como tratar de hacer un martini sin la ginebra.

El "senior" es en realidad muy poco calificado. Cualquier código que pueda compilarse (y pasar las pruebas si los tiene) debe comprometerse con el control de origen. El control de origen es un activo central para compartir código y construir SW de forma incremental.

Lo bueno es separar el código de producción (última versión estable), pero para ese caso los sistemas de control de fuente contienen características como etiquetas / etiquetas y ramas.

Nuestro equipo sospecha mucho si alguien no comete nada en dos o tres días. Significa que tiene algunos problemas y tal vez necesita ayuda. Otro punto de control de la fuente es que generalmente se realiza una copia de seguridad, lo que no es el caso de las máquinas de desarrollo. Si su disco falla, pierde su trabajo durante varias semanas.

Dejando a un lado la pregunta de si Joe tiene razón o no (está equivocado, por cierto), me parece que se podría llegar a un compromiso si utilizara un sistema de control de versiones distribuido como Git o Mercurial .

De esa forma, usted y el otro desarrollador trabajarían en su repositorio local, comprometiendo sus cambios al control de origen temprano y con frecuencia, pero no enviarían sus cambios al repositorio de "producción" hasta que estén "probados y aprobados como listos para producción". Tendría un historial completo de todo lo que trabajó en el transcurso de las semanas, y Joe tendría un repositorio prístino que solo tenía el historial de cambios que fueron bendecidos como listos para la producción.

No tiene sentido, por las mismas razones que enumeró. Es como usar el control de versiones sin los beneficios de usar el control de versiones.

Creo que Joe no ha entendido que los sistemas de control de código fuente no son copias de seguridad glorificadas de las versiones de producción de código fuente, sino una herramienta útil para los programadores al poner palabras en los pasos más pequeños del progreso y la maduración del código para su futuro yo y sus colegas. ¿Quizás Joe no está acostumbrado a trabajar en equipo con el código de otras personas?

¿Alguna vez consideró "por qué se agregó esta línea de código"? Localice el commit que lo introdujo y vea su comentario. Si solo se compromete cuando entra en producción, los comentarios no serán lo suficientemente específicos como para serle útiles.

También te sugiero que uses una herramienta más poderosa que SVN. Puede ver una buena introducción sobre las posibilidades en http://hginit.com/ por Joel Spoelsky.

Él usa mercurial, y hay varios contendientes en estos días. Git se considera muy poderoso, y https://github.com/ tiene algunas herramientas muy útiles y proporciona cuentas de inicio gratuitas para que pueda probarlo de verdad.

Joe no parece saber sobre SVN, trata de averiguar sobre ramas, etiquetas y troncales ... Etiquetas es coherente con lo que Joe quiere. Un poco de lectura sobre las mejores prácticas de SVN no haría daño

Nunca usé SVN, así que no sé cuáles serían los procedimientos para esto. Estamos usando ClearCase, y la práctica aquí es que cada desarrollador tenga su propia rama de desarrollo, luego una rama de integración a la que nos fusionamos cuando estemos listos para comenzar a probar, y una o más ramas de lanzamiento para código integrado y probado .

Joe es un hacker, no un desarrollador. Parece un hacker muy bueno, pero está equivocado acerca de cómo usar el control de revisión. Entonces, ¿qué hacer al respecto?

Me parece que su organización tiene una inversión en SVN, y sería una carrera limitada para usted desafiar a Joe e invalidar la inversión en dólares en el servidor SVN. Configure un repositorio GIT y use la interfaz git svn para trabajar de la manera que desee (todo esto es software gratuito y la configuración demorará entre una hora y un día, todo en su estación de trabajo). Socialice su flujo de trabajo con Joe: puede preservar su sistema de creencias de "reposo SVN no contaminado" y mantener su credibilidad sobre el costoso elefante blanco en la esquina (y el ego).

En poco tiempo, espero que Joe vea cómo trabajas y empiece a hacer lo mismo. En uno o dos años, el servidor SVN se convertirá en un repositorio de Git.

Podrías tratar de convencer a Joe con los argumentos anteriores. Si esto no tiene éxito, use SVN localmente para su propio trabajo de desarrollo y espero que Joe lo recoja en algún momento. Si no puede convencerlos con argumentos, haga lo que convenció y muéstreles que funciona. Tipo de enfoque distribuido pero con las herramientas existentes.

Voy a hacerme eco de @ Carson63000 aquí y decir que he visto esta actitud antes, y es en gran parte causada por las horribles capacidades de ramificación / fusión del VCS. Tener una rama que compila y pasa las pruebas, con etiquetas para cada versión, es un gran enfoque, pero no debe seguirse hasta el punto de que no se confirme ningún otro código. DVCS en general, y git en particular, hacen que la ramificación sea una operación fácil y común y reduce muchas de las dificultades con este flujo de trabajo.

La razón por la cual los sistemas de control de versiones admiten etiquetas es porque puede etiquetar el código certificado y aún así tener su trabajo diario comprometido. Siempre que tenga un código de calidad de producción, lo confirme, ralle una etiqueta y listo. Usted sabe el punto exacto en el 'tiempo' al que tiene que regresar para obtener lo que tiene el cliente. Y siempre puede verificar y comparar diferentes versiones de su código. De esta manera, ambos pueden estar contentos con lo que tienen en la base de datos de control de origen. Funciona para la empresa para la que trabajo, que tiene 100 desarrolladores, todos trabajando en el mismo proyecto. Definitivamente funcionará para usted también.

Es bastante común almacenar cosas solo en sistemas de control de versiones que estén listos para su entrega a producción. Así es como se ha hecho históricamente durante décadas, desde los viejos tiempos cuando el almacenamiento en disco costaba cientos de dólares por megabyte y almacenar todo era demasiado caro.

Ya no se considera la mejor manera de hacer las cosas, pero puedo entender completamente por qué la gente todavía lo hace, ya que muchos sistemas de control de versiones más antiguos todavía están en uso y hacen que sea difícil, si no imposible, hacer otra cosa y aún conservan el conocimiento de lo que cada versión es (o mejor dicho, no hay forma de saber qué es una versión sin verificar las etiquetas en todos y cada uno de los archivos si necesita regresar. He visto más de un repositorio donde la única forma de recuperar un archivo antiguo El lanzamiento era recuperar del repositorio un archivo zip con el código fuente y los archivos binarios para ese lanzamiento).