¿Cuáles son los riesgos al usar Rational Team Concert?

Question

¿Cuáles son los riesgos relacionados con el uso de Rational Team Concert en el desarrollo de software?

Answer 1

Rational Team Concert? Los riesgos son: Bloqueo del vendedor, no adecuado para su propósito, no coincide con sus flujos de trabajo, falta de comprensión o entrenamiento

Reloj de tiempo real? falta de precisión para su aplicación

Control de tiempo real? Garantizando la latencia. Especialmente en sistemas operativos que no proporcionan nada específico para él. Además, las aplicaciones RTC tienden a tener un alto grado de subprocesamiento y requieren programadores que adopten un enfoque muy estratégico para administrar la concurrencia y lograr el control en tiempo real.

Answer 2

¿Bloqueo del vendedor Team Concert? Dudoso. Siempre puede exportar su repositorio de SCM completo a Subversion de inmediato. Todos los elementos de trabajo se pueden exportar a través de archivos CSV ... O puede usar el Java SDK provisto para exportar todo ... Creo que lo hicieron lo menos posible.

Answer 3

Formo parte de un equipo pequeño que ha estado usando el cliente de Visual Studio 2010 de Rational Team Concert (RTC; primera versión 2 y ahora versión 3) todos los días durante aproximadamente 9 meses.

Acepto los comentarios de Benjamin sobre el bloqueo de proveedor. El riesgo de "falta de entendimiento o entrenamiento" se ha manifestado muchas veces para nosotros.

recomiendo encarecidamente contra el uso de RTC para el control de código fuente en Visual Studio, y cualquier usuario de Visual Studio con libertad para elegir su herramienta de control de código fuente debe ser capaz de encontrar una alternativa adecuada, sin demasiado esfuerzo. El seguimiento de elemento de trabajo/etc (conjunto de características de control no fuente) es bueno, pero aquí hay algunas reflexiones sobre su integración de control de origen con VS2010.

Hemos aprendido que panel "cambios pendientes" de RTC no es digno de confianza en su superficie - debemos constantemente (y manual) "refrescar" el panel de aprender qué diferencias hay verdaderamente son entre nuestras estaciones de trabajo y el repositorio . No es raro que compartamos nuestro trabajo con el equipo, solo para descubrir que algunos de los archivos fueron no enviados al repositorio (lo que resulta en una compilación rota para los compañeros de equipo), a pesar del panel 'Cambios pendientes' que nos dice que no los cambios estaban pendientes después de que "entregados" (el término de RTC para un "check-in") para el equipo.

Para empeorar las cosas, esta confusión de "Cambios pendientes" ha causado que nuestro equipo, muchas veces, pierda el código por completo. En cualquier grado que nuestra ignorancia o supervisión haya causado estas pérdidas, no las hemos experimentado con productos alternativos de control de fuentes. Considera que el cliente de RTC piensa no tenemos ningún "cambio pendiente" cuando aceptamos el trabajo de otros (aceptar otro cambio de desarrollador en un archivo que ha modificado puede sobrescribir sus cambios si RTC no se da cuenta de que Cambié el archivo).

Las ofertas "Mostrar historial" y "Comparar con anterior del repositorio" del cliente se deshabilitan intermitentemente en nuestros menús contextuales. En estos momentos, las soluciones manuales necesarias para ver (o anotar) el historial de revisión de un archivo son laboriosas en el mejor de los casos.

Si tenemos demasiados archivos modificados en nuestra estación de trabajo en un momento dado, el panel "Cambios pendientes" deja de mostrarnos una lista de los archivos; en su lugar, muestra un recuento. La cantidad de archivos modificados simultáneamente necesarios para que esto suceda es de cientos (es un número grande, sin dudas), por lo que es bastante raro que veamos esto, pero no es extraño que las refactorizaciones grandes en grandes bases de código afecten a estos muchos archivos. .

Estos son defectos alrededor de un solo panel. Otros comportamientos alrededor de las ofertas de control de origen del cliente son fallas/poco intuitivas, también.

En general, el cliente RTC2 VS2010 (la mayor parte de mi tiempo de uso) ofrece un nivel de calidad que asocio con un producto beta. El cliente VS2010 de RTC3 (del que hice todas las observaciones anteriores) es mejor y trae nuevas características (por ejemplo, la capacidad de establecer un elemento de trabajo actual), pero no se lo recomendaría a ningún usuario de Visual Studio con opciones que elija un producto de control de fuente. Sigue siendo más problemático y consistentemente sospechoso.

Answer 4

Soy parte del equipo de desarrollo que desarrolló RTC Client para Visual Studio, y me decepciona saber que su experiencia con RTC VS Client no ha sido satisfactoria. Volví y analicé los defectos en los que ha iniciado sesión en jazz.net: parece que hemos resuelto la mayoría de ellos y los que permanecen no hablan de la fiabilidad de la vista Cambios pendientes, ni de los elementos del menú que están desactivados inexplicablemente. .

No hemos tenido quejas similares de otros usuarios, por lo que le solicitaría que registre los defectos contra los problemas que ha descrito en esta publicación, con archivos de rastreo. Creo en algunos de los defectos que ha dicho que no podrían reproducirse; si aún los está experimentando, vuelva a abrir esos defectos.

Saludos --Rupa

Answer 5

Para responder a la pregunta original, mi equipo y yo hemos estado usando el cliente de VS de RTC desde nuestro primer hito hace años alrededor de 3 y medio y tenemos una gran base de usuarios ahora, entonces recomiendo publicar esta pregunta en https://jazz.net/forums/viewforum.php?f=17.

para responder a sus preguntas:

1. No hay dependencia de un proveedor-ins. Diría que tenemos una historia realmente abierta en comparación con muchas otras herramientas en el dominio de administración de cambios y configuraciones.
2. RTC tiene una buena historia de integración con Visual Studio. Es totalmente nativo, está basado en paquetes VS, y se integra bien con el explorador de soluciones de VS, las propiedades, las herramientas, la vista de errores, el marco de trabajo del editor, etc., dando una apariencia nativa para los usuarios de VS.
3. Hay un montón de blogs, artículos, videos y publicaciones en el foro sobre jazz.net; puede echar un vistazo a esos para hacerse una idea de la integración.
4. También puede crear un sandbox en jazz.net y conectarse a él utilizando el RTC VS Client para descubrir la experiencia por usted mismo.

Saludos

--Rupa

Answer 6

Los riesgos en no utilizando Rational Team Concert son

1. El uso de herramientas que no se integran bien con los demás. RTC cuenta con planificación integrada, seguimiento de errores, control de fuentes, compilación e informes. Para que pueda ver fácilmente qué correcciones se aplicaron a una compilación en particular, qué código se modificó y por qué. Puede comentar sobre el elemento de trabajo cuando no le gusta la corrección en el código, tome una captura de pantalla para ilustrar un punto.
2. Usar herramientas que no crecen con su proyecto. Puede comenzar rápidamente con RTC usando una plantilla de proceso predefinida.A medida que agrega más miembros, más equipos, más código, puede ajustar las reglas del proceso para decidir quién debe verificar los errores, ajustar las reglas hacia el final de un lanzamiento, automatizar las compilaciones, configurar las transmisiones escalonadas. etc. RTC es utilizado por equipos pequeños y grandes equipos.
3. Uso de herramientas que solo funcionan para desarrolladores o administradores, pero no para ambos. Con RTC, los gerentes pueden construir tableros sofisticados para rastrear el estado del proyecto en la interfaz de usuario web. Los desarrolladores pueden trabajar dentro de su IDE en Windows, Linux, Mac (Eclipse, VS en Windows). También hay una herramienta de línea de comando. Y se acerca más, su versión 4.0 Beta presenta un nuevo cliente Windows Explorer. Porque un IDE es genial para un desarrollador, pero no tan genial para un probador o un diseñador gráfico.
4. Usar herramientas que lo bloqueen en un sistema operativo en particular. Como dije en 3. tal vez hoy su proyecto sea principalmente Windows, pero ¿qué pasa mañana? RTC tiene clientes para Windows, Linux y Mac.

Pero al igual que voy a la tienda de Apple para probar el último gadget, se puede ir a www.jazz.net y descargar una prueba de RTC para ver por sí mismo. Importe un poco de sus datos y vea cómo se siente usted y su equipo.

Answer 7

El informe es débil. La información que necesita está allí pero es difícil hacerla llegar y en un formato que el cliente acepte. Necesito una matriz de trazabilidad de requisitos conforme a ProPath y su primo cercano, una Matriz de referencia cruzada de verificación (VCRM). Buena suerte con eso.

No es de código abierto. No tiene una comunidad de usuarios que busque en el origen para identificar y corregir vulnerabilidades. Esta última es la razón por la cual el Pentágono (el ejército de EE. UU.) Acepta cada vez más el código abierto; es difícil introducir un caballo de Troya en el código que todo el mundo está mirando.

Lo que no es un riesgo es que eventualmente pueda hacer su trabajo. Nadie fue despedido por elegir IBM. :-)

Answer 8

Utilizamos RTC en la oficina y funciona razonablemente bien. Aunque hay dos cosas que necesita saber:

• No es realmente un sistema de control de versiones distribuidas como Git o Mercurial. Funciona más como CVS. Sin embargo, admite conjuntos de cambios.
• No lo utilice con la base de datos derby. Se estrelló numerosas veces en nuestra situación. Ahora lo estamos ejecutando en DB/2 y ahora funciona de manera estable.
• También tiene soporte para el ciclo de vida completo de la aplicación, pero para mí es más una carga de un sistema hinchado que algo grandioso de tener.
• Es un gran sistema si vienes de CVS o Subversion.
• No es nada especial si vienes de Git o Mercurial.

Answer 9

Sé que este es un tipo de un hilo viejo, pero si otros vienen aquí, compartiré mi experiencia personal.

Lo hemos estado usando durante los últimos años y como cabeza de cartel RTC se ha convertido en un SCM, simplemente no confío en mis archivos.

Los flujos de trabajo son tan diferentes que otros SCM, en su conjunto, es un sistema complejo y complicado que de vez en cuando hace que pierda sus cambios.

El hecho de que haya un artículo sobre una supuesta característica llamada "Backup Shed" solo cuenta la historia de que no estoy equivocado, el hecho de que existe la necesidad de tal característica cuenta una historia en sí misma sobre cómo los cambios pueden desaparecer de repente - https://jazz.net/library/article/191/?errno=1

De otros SCM estamos bastante acostumbrados a que solo "revertir" sobrescribe los cambios locales. En RTC esto sucede en muchas otras ocasiones. Uno tiene que preguntar, lo difícil que puede ser posiblemente a unir los archivos y/o conflicto en estas situaciones ...

RTC sobrescribir archivos cuando:?

• sincronizar su espacio de trabajo, y puesto que usted no se puede registrar desde un WS no sincronizado, no se puede evitar esto, así que por dios, haz una copia de seguridad antes de hacerlo!
• Aceptando cambios, sí, a pesar de lo que hacen todos los otros SCM ... Sin embargo, le pedirá que compruebe los cambios locales antes de aceptar cambios, así que recuerde hacer clic en sí en ORA en que descubrió todo cambios locales
• ¿Al azar? ... Estoy bastante seguro de que he experimentado otras ocasiones en las que los cambios desaparecieron, pero solo los 2 anteriores han sido cosas que he podido detectar ...
• Revertir ... Obviamente, el solo una viñeta que debería estar en esta lista.

Esto puede ser por "diseño" ... Pero me gustaría votar uno por el diseño realmente malo.

También como se menciona, si está en Visual Studio, SIEMPRE haga clic en Actualizar cambios remotos y locales antes de registrarse. Una solución como subversión (tan antigua como es) son mejores millas para descubrir cambios que RTC, y así es GIT ...

Además, tanto SVN como Git tienen implementaciones geniales en muchos IDE también ... Creo que tardó un tiempo hasta que Git se volvió tolerable para usar en Visual Studio, ¡pero ahora sí lo es! Aunque todavía hay características que desear. SVN también se puede integrar con muchos sistemas de seguimiento de elementos de trabajo/problemas, pero para la integración de Jira, prefiero escribir los números de Issue en los comentarios, es más rápido y más fácil ... Y crea el enlace a medida que FishEye retoma el cambio establece, por lo que Jira mostrará compromisos en los problemas.

No puedo decir cómo Git/Stash combinado o SVN vs YouTrack/mezclan trabaja aquí. Pero en RTC, el flujo de trabajo de adjuntar elementos de trabajo a confirmaciones se convierte en una gran sobrecarga, por lo que dejamos de usarlo = Función sin valor.

Luego está la planificación de conjunto,-elemento de trabajo, etc. scrum parte del sistema ... La única parte que nunca me gusta de las que es las risas que me da de vez en cuando. Más allá de que es casi inútil ... Ir Jira + GreenHopper, se mezclan, YouTrack lugar ...

Una de las cosas divertidas es que IBM trata de vender esto en "Integración" y cuánto ahorrar en ese .. Dado que estas soluciones son tan amplias, hay un montón de buenas soluciones en las que, literalmente, puede configurarlas y no tendrá que tocar un dedo hasta que decida que es hora de actualizar a una versión más nueva de ese software. . Además de todo eso, los "supuestos ahorros de tiempo en los administradores" solo tienen que doblar para que funcionen y ayuden a resolver muchos de los problemas que RTC parece haber traído.

Así que aconsejaría contra la RTC. Y Github, CodePlex, etc. Bitbucket ha demostrado que más de cosas como Git, SVN etc. hace en escala de hecho ...