Ir contra el control de fuente común utilizado en la organización

La empresa para la que trabajo utiliza exclusivamente Clearcase. Siento que no vale la pena el esfuerzo de aprender y usarlo, ya que mi proyecto no involucraría a demasiadas personas (máximo de hasta 3 personas), tampoco implicaría un flujo de desarrollo sofisticado. ¿Cómo puedo convencer a mi gerente sobre el uso de un control de fuente separado para esto cuando mencionan el punto de "apoyo de TI y control de fuente uniforme en toda la empresa" en contra de mi sugerencia? ¿O es ese punto en particular válido y debería irme con Clearcase?

Gracias…

PD: estaba pensando en usar Subversion.

Si es el estándar de la empresa, entonces debe haber personas en la empresa que lo sepan que puedan ayudarlo a comenzar. Deben poder configurar su IDE particular para que trabaje con él, y hacer que todo sea lo más perfecto posible para usted. No debe tener que aprender nada loco para usarlo, debe haber instrucciones claras.

Si no es así, no obtendrá el beneficio de "control de fuente uniforme y compatible con TI en toda la empresa" y no importa cuál sea su uso.

Después de trabajar en este process, si se puede argumentar que hay un mejor control de fuente que funcionaría mejor a través de la empresa, debe hacerlo. Si es un estándar de la compañía, no debería ser un dolor de cabeza.

Primero que nada, mis condolencias.

¿Clearcase es tan difícil de aprender? Si es así, consideraría un ataque en contra. Si no es así, es mejor que te vayas con la stream y lo aprendas.

No es probable que las 3 personas de tu equipo sean las que mantengan el código sobre la vida del software, por lo que ese argumento también va en contra de ti.

¿Qué tan grande es la organización? Es más fácil para 3 personas aprender Clearcase que X para aprender Subversion.

Dependería mucho de su jefe y de su disposition a considerar alternativas.

Subversion sin duda sería fácil de configurar y usar. Odiaría usar Clearcase yo mismo.

Pero hay muchos factores en tu contra. Buena suerte.

Si yo fuera tú, me gustaría usar SVN porque me encanta, pero al igual que cualquier otra cosa que desarrolles la mayor parte del time, debes seguir el ritmo. Igual que si extendieras un marco y decidieras hacerlo a tu manera, completamente diferente al rest de la estructura, sería desaprobado, incluso si tu path fuera mucho mejor. ¿Qué pasaría si tu y tu equipo fueran atropellados por un autobús? OK SVN es fácil de aprender, pero todavía hay una curva de aprendizaje que podría ralentizar a otras personas que continúan con su trabajo.

También podría ver esto como una oportunidad para aprender un nuevo sistema de control de fuente y hacerse más comercializable. Aún puede preferir la subversión, no se le puede obligar a cambiar su opinión. Como @Erick dice que si este es el estándar de la compañía, deberían poder apoyarlo y espero que pueda tenerlo en count en sus escalas de time.

Siempre existe el enfoque probado y verdadero (aunque arriesgado) de que su equipo use Subversion (¡qué apropiado!) Dentro de sí mismo y haga el check-in de shows ocasionales en Clearcase.

Su argumento contra Clearcase es

  • no vale la pena el esfuerzo de aprender
  • mi proyecto no involucraría a mucha gente ni implicaría
  • flujo de desarrollo elegante

¿Es difícil de aprender? Si su empresa ya lo está usando, tendrá muchas personas para pedir ayuda. Debido a que su empresa ya tiene claro, está 80% listo con los trabajos administrativos de los rectores. Será bastante simple crear vobs, proyectos, etc.

De hecho, su proyecto es pequeño, lo que hace que sea más importante usar estándares dentro de la empresa. Hicimos algunos proyectos sofisticados usando nuestro SCM estándar y algunos proyectos sin el SCM estándar. Para el que usó SCM estándar, cuando los proyectos se descartan, el código sigue siendo seguro en la organización. Otros productos, perdimos gente y código.

¿Estás usando ClearCase con UCM? Es más simple que el claro de base.

Como mencioné en " ¿Hay alguna razón para seguir utilizando SVN? ", No puede decidir poner un nuevo server a un lado, especialmente para datos confidenciales como fonts de código. En algún momento, necesitan ser versionadas en un referencel central .

Cualquier server para ese tipo de datos persistentes e importantes debe ser:

  • financiado (no puedes simplemente administrar un VCS en tu estación de trabajo, necesitas un server real)
  • compatible (su trabajo es desarrollar, no administrar / solucionar problemas de su equipo en términos de operaciones de SVN)
  • integrado (no hay problema en ese frente para SVN)
  • administrado (una vez más, su trabajo no es administrar / supervisar el server SVN)
  • documentado (¿dónde está su server SVN ?, ¿cuáles son los procedimientos de copy de security ?, ¿hay algún server de respaldo / DRP? …)

Por todos estos motivos, su gerente podría considerar aprovechar la infraestructura / soporte existente alnetworkingedor del VCS principal (ClearCase, condolencias;)).

Pero eso no le impedirá administrar un DVCS dentro de una vista de instantánea de ClearCase .

No conozco Clearcase, así que no puedo decir si es bueno o malo o cómo se compara con Subversion.

Pero el objective principal del control de la fuente es que se supone que hay un único repository donde todos saben que pueden ir a verificar su código. Si un equipo usa Clearcase y tu equipo utiliza Subversion y otro usa Git y otro usa CVS, etc., entonces cualquiera que quiera verificar el código fuente no solo debe search en diez lugares, sino que debe aprender a usar diez códigos fuente diferentes. sistemas de control.

A less que pueda argumentar que Subversion es claramente mejor que Clearcase de alguna manera importante e importante, yo diría que solo muerde la bala y aprende Clearcase. Si fuera yo, lo vería como una oportunidad para aprender algo nuevo. Después de que lo hice, tal vez llegaría a la conclusión de que Clearcase apesta a lo grande y que debería tratar de convencer a los poderes fácticos de que cambien a otra cosa. O tal vez concluiría que Clearcase fue el mayor avance desde la invención de USB. De cualquier manera, ahora sabes un poco más. Si nada más, es una bala más para poner en su currículum la próxima vez que busque otro trabajo.

¿Está trabajando a time completo para esta empresa o es un proyecto único como contratista?

Si es su function de empleado a time completo, entonces es hora de comprar ese libro "Clearcase for Beginners".

Si está buscando entregar un proyecto rápidamente, entonces tal vez solo agache la cabeza y use Subversion como un recurso. Pídale a alguien que verifique el artículo terminado en Clearcase cuando salga corriendo por la puerta.

🙂

Usa un DVCS como Mercurial o Git y haz una ramificación para sincronizar con ClearCase. Su equipo puede hacer el trabajo diario utilizando una herramienta mejor, pero su organización todavía tiene acceso a los productos de su trabajo de la manera habitual (lo cual es importante). Sincronícese con ClearCase de forma periódica y considere agregar el resultado del logging DVCS de su sistema (por ejemplo, hg log) a un file en la sucursal de ClearCase, para que las personas puedan ver los pasos más detallados si es necesario.

Los sistemas DVCS también suelen ser bastante fáciles de configurar y, a menudo, se pueden alojar fácilmente en una networking compartida o algo así. Dado que todos los desarrolladores tendrán una copy del tree completo, proporciona una cierta cantidad de copy de security y networkingundancia integradas.

Este flujo de trabajo no es infrecuente: gitsvn y hgsvn son scripts que las personas han configurado para permitirles usar esas herramientas por sí mismos, pero sincronizarse con otras personas en otro repository.