Aldon and .Net Development

Question

Estoy buscando comentarios de los desarrolladores de .Net que tengan experiencia con Aldon como una plataforma de administración del ciclo de vida. Estamos considerando seriamente utilizar Aldon para la administración del ciclo de vida, incluyendo control de fuente, compilaciones automatizadas, etc. Sé que hay muchas otras opciones, pero la nuestra es una tienda AS/400 primaria (con programadores AS/400 que superan en número a los desarrolladores .Net) 6 a 1), y Aldon ya es utilizado por nuestro equipo iSeries. El beneficio que estamos buscando es tener un conjunto de administración de ciclo de vida.

Básicamente, estoy buscando opiniones de personas que han usado Aldon y otro conjunto de herramientas (quizás TFS, o una combinación de SVN, Cruise Control, etc.). Si trabajó con ambos, ¿tiene alguna recomendación sobre si es una buena idea o una mala idea? Obviamente es una gran opción, por lo que cualquier comentario sería útil.

Editar - Añadido

No hay respuestas o comentarios ... y mi primera placa Tumbleweed. No estoy seguro de si esto es solo una mala pregunta, si realmente nadie usa Aldon para administrar su trabajo .NET, o si simplemente nadie usa Aldon que usó otros productos y puede ofrecer una comparación.

Por lo tanto, estoy ofreciendo una recompensa para endulzar el trato, y ampliando el alcance de la pregunta ... Si hay alguna persona por ahí UTILIZANDO Aldon en absoluto, ¿puede proporcionarnos información sobre los problemas que ha tenido? ¿es un buen conjunto de herramientas, frustraciones o trampas, cosas que amas, etc.?

Agregado -incluso más Nuestro objetivo principal es tener un producto para gestionar tanto nuestra .NET y nuestro desarrollo AS/400 (principalmente RPG). Si tiene una sugerencia para un conjunto de herramientas diferente, o lo ha intentado y ha decidido que no lo vale, también tomaré esa respuesta.

Answer 1

Estoy trabajando en una tienda similar a la suya; en nuestro caso, existe una base de código heredado sustancial de código iSeries COBOL y un número creciente de sistemas .NET, y los desarrolladores de .NET han presionado con éxito usar Subversion para el control de fuente En mi breve tiempo de evaluación del producto, parecía que Aldon no era muy flexible en áreas como ramificación y etiquetado, y tiene una interfaz muy engorrosa y arcana. Como los ciclos de vida de los productos se administran (mal) por separado en nuestra tienda de todos modos, lo que limita el uso de .NET de Aldon al control de fuente solamente, fue una decisión simple. En el mundo de .NET, Aldon está muy por detrás de las herramientas estándar de código abierto en características y usabilidad, y no tiene esperanzas de competir con TFS. En nuestro caso, la administración del código .NET fuera de Aldon definitivamente ha aumentado la productividad del desarrollador y disminuido la frustración.

Un ejemplo ... viniendo de una tienda de Subversion, estaba tratando de descubrir cómo crear una sucursal experimental en Aldon. Si es posible, la documentación hizo un excelente trabajo al ocultar la función, y nuestro administrador de Aldon nunca se había encontrado con el concepto. Todo en nuestra tienda está cerrado con seguridad, con los derechos de administrador necesarios para crear proyectos, versiones, etc.Esto puede valer la pena desde el punto de vista de la administración del ciclo de vida, pero desde la perspectiva de un desarrollador que intenta hacer el trabajo, es un asesino. No creo que la gestión del ciclo de vida y el control de origen pertenezcan al mismo software, y Aldon no ha hecho nada para disuadirme de esa opinión.

Answer 2

Creo que encontrará que nadie aquí lo usa. Las personas de .NET se dividen en dos categorías: las que son "baratas" (es decir, que intentan ahorrar costos) y, básicamente, se ven o algo así como de código abierto. Y aquellos que pagan mucho, y la mayoría de ellos van con Team System, porque se integra en Visual Studio de abajo hacia arriba. AS/400 es una mezcla bastante rara para desarrolladores de .NET, por lo que, al final, es posible que no haya tenido suerte.

Personalmente, no estoy seguro de que me moleste con eso. Hay mucho más para Team System que tracking source, etc. - muchas buenas características de prueba, compilación en integración continua, etc., y todo eso sin pasar por capuchas para obtener un producto inferior.

Answer 3

Nos encontramos con el mismo problema en mi lugar de trabajo hace unos años cuando comenzamos nuestro primer proyecto .NET en medio de un grupo de desarrolladores de rol. En ese momento, elegimos usar un sistema de control de fuente separado (Subversion) para cualquier cosa escrita en .NET (o para cualquier otra cosa que alguien quisiera usar). Trasladamos todos nuestros proyectos (.NET y AS/400) a Gemini para fines de seguimiento de tiempo y defectos. Básicamente, elegimos un solo producto para administrar nuestros proyectos .NET y AS/400 a un alto nivel pero diferentes herramientas para control de versiones, compilaciones automatizadas, pruebas automatizadas, etc.

Años más tarde puedo decir felizmente que esto ha funcionado muy bien para nosotros. Realmente no puedo pensar en ningún problema que esto haya causado, pero puedo dar fe del hecho de que ha evitado algunos posibles dolores de cabeza y ataques de cabezas. Creo que será más fácil encontrar desarrolladores de .NET (buenos) al elegir un sistema de control de versiones ampliamente utilizado. No puedo hablar por nadie más, pero para mí el uso de un sistema de control de versiones que tengo nunca he oído hablar de sería una especie de bandera roja en una situación de entrevista.