¿ClearCase se ajusta a nuestro process de desarrollo?

Entonces, permítanme describir nuestra situación actual. Somos un pequeño equipo (6) de experimentados desarrolladores de Java, perdidos en un gran equipo de SI compuesto principalmente por los configuradores de SAP y Siebel.
Mientras todos los otros equipos estaban usando VSS, principalmente como un sistema de bóveda, nuestro equipo había cambiado para Subversion (después de evaluar DVCS también) como mejor se ajusta a nuestra metodología ágil.

Ahora, a todos se les pide que pasen a ClearCase, y todo el esfuerzo de migration se hace a los usuarios de VSS ya que son la parte más grande de los usuarios.
Como nos quedamos solos y no conocemos realmente ClearCase, tenemos cierto temor de que no se ajuste a nuestro process de trabajo actual.

Aquí está actualmente cómo estamos trabajando diariamente:

  • El repository SVN sigue la estructura / trunk, / branches, / tags.
  • Cada desarrollador tiene su propia caja de arena en el repository, para fines de testing y creación de prototypes.
  • Usamos twigs intensamente para el desarrollo de nuevas características y las usamos para unirlas para realizar algunas testings de integración antes de volver a promocionarlas en el troncal.
  • Trabajando en Java, estamos acostumbrados a hacer refactorizaciones, y Eclipse es una gran ayuda para eso. Muchas classs y packages cambian de nombre todos los días.
  • Dependiendo de cómo evolucionaron los proyectos, algunas piezas pueden reutilizarse, lo que da como resultado una split de un proyecto en varios proyectos, el original permanece integrado a través de la propiedad svn: external.
  • Usamos la sustitución de palabras key para algunos elementos, ya que es una forma extremadamente simple de saber para el probador qué revisión está probando.
  • Nuestro repository Subversion está vinculado a Hudson para ejecutar suites de testing y promover comstackciones válidas etiquetándolas.

Todo lo que sé sobre ClearCase por el momento es que tendremos que usarlo a través de CCRC (oa través de su versión de complemento eclipse), y que es muy alentador que hayamos vinculado la mayoría de nuestros proyectos a un proyecto ClearQuest para la gestión de seguimiento de problemas .

¿Podría aclararnos qué tan bien ClearCase sustituirá nuestra Subversión, qué conceptos tienen una coincidencia exacta (no me importan los sinónimos, sino realmente los conceptos) y qué tipo de cambios podría prever en todo el process.

Gracias.

Primero, aquí hay algunas publicaciones que puedes leer sobre ClearCase:

  • ¿Cuáles son los conceptos claros básicos que todo desarrollador debe saber?
  • Cómo aprovechar las características de Clearcase
  • Ventajas / desventajas de ClearCase

Ahora:

  • CCRC significa "vistas web", es decir, vistas de instantáneas en un server web dedicado a ClearCase … es mejor tener una buena LAN entre su escritorio y ese server.

  • las sucursales son ciudadanos de primera class en ClearCase, lo que significa que una vista de ClearCase determinada (aquí una instantánea ccweb) solo le dará acceso a una sucursal. Si está acostumbrado a trabajar en varias sucursales a la vez, necesitará varias vistas.

  • todas las operaciones son file por file, por lo que la idea de trabajar en una twig privada, luego fusionar es engorrosa debido a la cantidad de fusiones involucradas.
    Recomiendo encarecidamente trabajar en una twig común para un esfuerzo de desarrollo dado que varios desarrolladores desean abordar.
    Si quieren sucursales privadas y sandbox, pueden configurar una vista de Git dentro de su vista ClearCase sin problema.
    (Nota: una vista de instantánea no se puede considerar como un entorno limitado: cuando ingresa un file, cada otro desarrollador verá los cambios cuando hagan una actualización de su vista de instantánea)

  • el plugin ClearCase Eclipse admite refactorización.

  • la noción de svn: external no es realmente compatible con ClearCase, excepto a través de enlaces. O a través de dependencies de línea base de UCM.
    Se debe tener en count que es más fácil trabajar con dependencies binarias que con dependencies de fonts: si su externo es para include los miles de files fuente del próximo proyecto, será engorroso en ClearCase (debido a las actualizaciones prolongadas). Si incluye algunos jar o dll, eso es mucho más rápido (más esos serán los que realmente se desplegarán).

  • Si está trabajando con UCM, no será posible mover códigos de un componente a otro. Deberá clearfsimport las tags principales en el nuevo componente "común" identificado.

  • Nota: la sustitución de palabras key de RCS generalmente se considera … maligna 😉 Recomendaría un file de text separado con la versión o las tags de los files importantes relevantes en él. Eso funciona bien para los materiales de entrega, no para los files fuente.

En mi opinión, CC es una mala opción para el equipo ágil. En principio, podrá trabajar con él, pero inevitablemente perderá su productividad hasta cierto punto. La cantidad de ese grado depende de cuán buenos y comprensivos sean sus administradores de CC. Deben entender claramente las necesidades del equipo de desarrollo.

En nuestro equipo, pasamos momentos muy malos con CC. Nuestros administradores son remotos y están aislados del rest del equipo, por lo que nos vemos obligados a comunicarnos con ellos a través de correos electrónicos y un rastreador de requestes. Puedes imaginar cuánto time lleva. No podemos actualizar a las últimas versiones de CC debido al costo y la complejidad de este process (y una cierta carga administrativa, supongo). Entonces, usamos CC / CCRC de las versiones 7.0.

CCRC de esta versión es una mierda. No puedes refactorizar fácilmente con él. No puede realizar una combinación arbitraria con él. No puedes crear línea de base. Ni siquiera puedes poner los files en la list de ignorados. Por cierto, hasta donde yo sé, CC admite files ignorados solo en las últimas versiones de CCRC y no en el cliente CC nativo. Nuestra versión CCRC no tiene interfaz de línea de command.

CC depende en gran medida de la comunicación del server y, por esta razón, CC (y CCRC) dejan al desarrollador por sí solo cuando intenta trabajar fuera de línea. El repository de CC no se puede utilizar remotamente sin CCRC o escritorio remoto (el time de respuesta del clic del mouse es del order de minutos).

CC interfiere con otras herramientas porque marca todos los files como de solo lectura y requiere que se desprotejan explícitamente antes de la modificación. Entonces, al tener el plugin de Eclipse, puedes refactorizar. Pero con cualquier otra herramienta no tienes suerte. Deberá verificar los files antes o modificarlos a la fuerza, convirtiéndolos en pirateados. Si usa otras secuencias de commands IDE, sed o awk o algo similar, tendrá problemas. E incluso si solo usa Eclipse, las operaciones que involucran CC (es decir, todas las refactorizaciones de networkingenominación, etc.) son lentas porque CC es lento.

Lo único bueno de CC es que es bueno para fusionar y fusionar el seguimiento. Pero Subversion 1.5 se acercó bastante a ese punto. Y de todos modos, no me convence usar CC.

Admito que mi aguda opinión negativa está formada principalmente por mi mala experiencia personal. Pero estoy seguro de que incluso en la configuration de CC ideal con un process y administración perfectos, su productividad sufriría de todos modos. Eso se debe a la dependencia excesiva de CC en el server y al "Check out-check in" con un estricto enfoque de locking. Proporciona algunos "soluciones alternativas" (prefiero llamarlos kludges) a esto como salidas sin reservas y estado de secuestro, pero agregan sus propios problemas. CC se interpone constantemente entre usted y su código.

Y, por cierto, supongo que IBM Rational tarde o temprano trasladará a sus clientes a la plataforma Jazz . Su Rational Team Concert es algo con "sabor ágil". Tiene edición gratuita para 10 desarrolladores y alguna integración con CC (pero no estoy seguro de si es gratis). Entonces podrías intentarlo. Sin embargo, no creo en nada bueno de IBM Rational.

Aquí está el problema con ClearCase:

ClearCase fue creado en la década de 1990 cuando su estación de trabajo en su sistema de escritorio ni siquiera tenía una unidad de disco, y mucho less espacio. Además, su sistema de escritorio probablemente tenía memory limitada y era lento.

ClearCase fue una gran respuesta. Las vistas podrían vivir en un server de visualización. Los VOB viven en un server Vob. Máquinas dedicadas que son rápidas, rápidas, rápidas.

ClearCase había derivado objects que podían guiñarse en lugar de hacer que su máquina lenta intente comstackr el código. ¡Qué ahorro de time fue eso!

Y, la estructura VOB de ClearCase significaba que podía hacer cosas que pocos sistemas de control de versiones podían hacer. Por ejemplo, podría cd en un file si agregó @@ en el nombre. Eso le permitió ver todas las twigs, tags y todas las versiones de ese file. Simplemente podría ejecutar sus herramientas estándar de Unix para search diferencias, etc.

Entonces, el mundo cambió:

  • Los sistemas de escritorio se hicieron más potentes. Usted tiene el espacio de disco, la memory y la potencia de procesamiento en bruto. La creación de un área de trabajo de finalización de la compra en su disco local (y ciertamente tenía uno) significaba que no tenía que depender de la networking que se estaba volviendo más lenta a medida que aparecían más y más processs de networking. ¿Guiño en un object derivado? Diablos, mi máquina podría build el bombeo cinco veces más rápido que ClearCase podría localizar un object derivado apropiado.

  • Windows. ClearCase fue diseñado con Unix en mente. Los ganchos podrían operar en el sistema local porque todos tenían Perl instalado en su escritorio, y usted fácilmente podría asegurarse de que todos estuvieran en la misma revisión. Diablos, podría tener un directory / usr / local montado en NFS (lo sé, pero local directorys local networking eran comunes) con la versión correcta de Perl o lo que sea que esté instalado, y sus ganchos funcionarían. Windows no jugó tan bien. Ganchos se convirtió en un dolor de cabeza.

  • Windows nuevamente: ClearCase depende de las herramientas de Unix para funcionar bien. Windows no los tenía.

  • Desarrollo ágil: cuando se desarrolló ClearCase, el model de desarrollo consistió en aislar a los desarrolladores entre sí. Podría trabajar mucho más rápido si no tuviera que preocuparse constantemente de que otro desarrollador realice cambios en su sistema. En ClearCase la bifurcación fue fácil. Podría darles a todos su propia sucursal, y luego podrían fusionarse con la sucursal principal cuando terminen. ¡Fusiona ida y vuelta! Es fácil en ClearCase. Diablos, UCM está construido sobre la base misma. Desafortunadamente, la estrategia exigió una disciplina completa. Debes seguir recordando a los desarrolladores que fusionen su código para que otros desarrolladores puedan verlos. Hubo una inevitable crisis de fusión justo antes de un lanzamiento, ya que docenas de desarrolladores intentan fusionar sus cambios con la twig de integración. El desarrollo ágil elimina el concepto de aislamiento del desarrollador. Haces pequeños cambios y haces un seguimiento de lo que otros están haciendo. Por lo tanto, el concepto de "Oprah Branching" (¡Obtienes una twig! ¡Obtienes una twig! ¡Todos obtienen una twig!) Ya no se usa.

  • Entonces, ahora tienes un sistema rápido con mucho espacio en disco y memory. Puede tener tres o cuatro cajas por separado a la vez. La ventaja de la vista dinámica simplemente no superaba su desventaja de ser lento y intensivo en la networking. Las vistas de instantáneas ayudan, pero eliminan toda la magia de ClearCase que alguna vez tuvo. En otras palabras, ¿por qué utilizar un sistema tan grande y voluminoso como ClearCase como CVS cuando simplemente se podía usar CVS en primer lugar?

  • Por último, ClearCase es difícil. En los viejos times, cuando los desarrolladores eran todos expertos en sistemas y networkinges, podía aprenderse los entresijos de ClearCase. Hacer vistas no fue más difícil que aprender la syntax de YACC. Sin embargo, los desarrolladores no son tan expertos en sistemas como lo fueron antes. ¿Por qué deberían ser? No necesita saber cómo funciona la memory para progtwigr en Java o C #. Los desarrolladores ya no quieren aprender acerca de 100 herramientas diferentes para hacer su trabajo. La capacitación de ClearCase puede tomar unos días, y aprender los pormenores de ClearCase puede tomar semanas. En ClearCase, tengo que entender la syntax de vista para hacer cosas simples como modificar el código en una twig. Con CVS, es solo un command.

ClearCase simplemente es demasiado complejo, lento y costoso. Y, gran parte de esto fue la apuesta que Atria tomó cuando construyeron ClearCase: 1). Los desarrolladores estarán dispuestos a aprenderlo porque de todos modos tienen que aprender otras 100 herramientas. 2). Su máquina de escritorio es lenta y pequeña en comparación con los serveres de networking. Hacer todo "en la nube" es más rápido. 3). Las capacidades de centralización de ClearCase son una gran ventaja para las empresas, ya que un sitio puede administrar y respaldar todo.

Las tres suposiciones resultan ser falsas, y debido a eso, cada vez less empresas están considerando ClearCase. Quizás cuando Rational compró PureAtria, si Rational lo trajo al siglo XXI para hacerlo más pequeño, más liviano y más barato, podría ser una herramienta ampliamente utilizada. Pero, Rational estaba demasiado ocupada haciendo que el desarrollo fuera más enrevesado para poder integrar todas las ingeniosas herramientas que compró en un process de desarrollo centralizado. Para cuando IBM compró Rational, ClearCase comenzaba a sangrar a los usuarios.

Gizmo,

Actualmente estoy pasando por el mismo problema que tú, excepto desde la otra perspectiva: soy un administrador de ClearCase que intenta migrar un equipo de SVN a ClearCase.

CCRC se promociona como la herramienta a usar para desarrollar Java. No estoy del todo seguro de creer eso: CCRC (The ClearCase Remote Client) se ha diseñado para ayudar a los desarrolladores que trabajan de forma remota desde la infraestructura principal. El código se guarda en el escritorio para ayudar en las velocidades de acceso, pero hay una sobrecarga de input y salida que no se puede ignorar.

La refabricación es técnicamente posible desde CCRC, pero no es posible realizar una refactorización si se desconecta de la infraestructura: la herramienta no lo permite.

También hay otros problemas con los espacios de trabajo de Eclipse que se ajustan muy bien con las vistas de CCRC: es posible que (según la estructura de bifurcación de su entorno) tenga problemas con los nombres de las routes absolutas para las herramientas.

Algo para tener en count, y quizás para mirar, es que ClearCase sí hace vistas instantáneas de vanilla. No estoy de acuerdo con VonC (tal vez por primera vez, es un gran administrador) porque creo que las vistas de CCRC (que se denominan vistas web) son bastante diferentes de las vistas de instantáneas nativas que te permiten desarrollarte en un entorno mucho más parecido SVN, especialmente si estás buscando hacer Java Development.

En cuanto a ClearCase y Hudson, he hablado con Andrew Bayer para que el plugin ClearCase funcione un poco más fácilmente con Dynamic Views, que entró en juego en la versión 0.9. Es un miembro bastante activo de la comunidad de Hudson, por lo que si tiene problemas con el complemento, los problemas planteados deberían repararse con bastante rapidez.

Sin embargo, el mayor consejo que puedo dar es que solo porque es diferente, no significa que sea peor. Sea paciente, se sorprenderá del nivel de control que ClearCase puede brindarle si lee los documentos y se toma su time.

¡Buena suerte!

Stuart

Clearcase es una poderosa herramienta de administración de configuration de software y la mayoría de las cosas que describió como sus actividades diarias son posibles a través de Clearcase.

Clearcase tiene el concepto de vistas que es similar a la caja de arena que ha mencionado. Con algunos conocimientos básicos de especificación de configuration (set de reglas para elegir versiones de elementos del repository), es más fácil realizar una bifurcación y existe un buen soporte para la fusión de cambios realizados en diferentes twigs.

Una actividad de la que no estoy seguro si es compatible o no es la sustitución de palabra key. Incluso si el soporte de Clearcase no sustituye las palabras key, puede crear un desencadenante de preinscripción para hacer la sustitución de palabras key de forma automática.

Pero no está claro si toda su interacción con Clearcase será solo a través de CCRC (cliente remoto de Clearcase). No he usado CCRC y no sé qué cosas son compatibles a través de CCRC.

clearcase es el sistema de versiones más poderoso que he conocido. Todas las tareas enumeradas son compatibles.