2009-03-01 4 views
10

Estoy trabajando en la transición de mi proyecto actual de aproximadamente 20 desarrolladores a un entorno moderno de desarrollo y construcción. Actualmente usamos un sistema de control de fuente basado en RCS y un sistema de seguimiento de problemas asociado, ambos con UI de Motif. No hay un proceso formal de creación de producción, es lo que sea que funcione.¿Qué herramientas de desarrollo y generación de vida utilizas?

Estoy interesado en:

  • Herramientas de desarrollo
  • de control de versiones
  • seguimiento de asuntos
  • gestión de la dependencia
  • Gestión de la Configuración
  • Automatizado de construcción
  • prueba automatizada
  • integración continua
  • Gestión Artefacto
  • administración de la versión
  • Deployment Management
  • Requisitos Trazando
  • ¿Qué más?

Me interesan no solo las herramientas que utiliza, sino qué tan bien se integran entre sí, qué tan fáciles son de configurar y usar, y cómo les gusta tanto a los desarrolladores como a la administración. Nuestro proyecto es una combinación de Java, C++ y VHDL, pero aún me gustaría recibir noticias de personas con otros idiomas. Actualmente estoy yendo por el camino de eclipse, subversión, trac, maven, hudson y nexus.

Además, ¿hay un término mejor que "Build Lifecycle" que abarque no solo la construcción, sino también el flujo de código desde que el desarrollador lo crea hasta cuando se construye, prueba y en un sistema de producción? El "ciclo de vida de compilación" parece limitado, pero el "ciclo de vida del proyecto" ya está tomado.

Respuesta

2
  • Herramientas de desarrollo JetBrains IntelliJ IDEA
  • de control de versiones Subversion
  • seguimiento de asuntos Atlassian Jira
  • Dependencia de Gestión Maven
  • Configuration Management TeamCity
  • Automatizado de construcción TeamCity
  • de prueba automatizada de JUnit (?)
  • integración continua TeamCity
  • Artefacto Gestión Maven
  • Release Gestión Homo Sapien
  • Deployment Management Maven/Homo Sapien
  • Requisitos Trazando de quimérico
  • una sola vez Automatización Bash
  • desarrollador a desarrollador de documentación MediaWiki
4

Odio a Maven menos de lo que odio a Ant, y para Java, tiene que elegir uno de esos males. Si recién está empezando, elija Maven, especialmente porque ya ha reconocido que su "ciclo de vida de construcción" abarca 12 disciplinas diferentes y complejas. Tendrás que elegir convenciones para todos ellos. Ahórrese los problemas y siga las convenciones que Maven ya estableció.

Para integración continua y automatización general de compilación, me gusta Hudson.

3

Durante los últimos dos años pasamos gradualmente de una estrategia de "cada proyecto tiene su propia herramienta" a una solución Trac + SVN + SCons y estamos muy contentos con eso.

El cambio a SCons fue un poco duro, pero realmente valió la pena. Tenemos un entorno heterogéneo, principalmente C/C++ para diferentes plataformas integradas, módulos kernel, algunas aplicaciones de escritorio y varios módulos Python como código de pegamento. SCons realmente brilla cuando desea agregar soporte para sus propios compiladores y herramientas de nicho y necesita adaptar el sistema de compilación a sus requisitos. Anteriormente, teníamos que utilizar una GUI diferente para casi todas las plataformas integradas: ahora que SCons invoca directamente a los compiladores, el ciclo de trabajo ha mejorado ligeramente.

Nuestros desarrolladores utilizaron Emacs o Vim y nadie quería cambiar a nada más, así que (afortunadamente) nos quedamos con eso. No estoy muy familiarizado con el despliegue, así que no puedo hablar de eso.

1

Somos una tienda de MS que utiliza VS2008. Usamos Subversion con Tortoise para SCC y control de versiones, y nuestro repositorio está alojado en línea para que nuestro equipo distribuido pueda usarlo. Para la compilación, estamos utilizando Hudson y CI, mucho mejor que Nant o MSBuild. El seguimiento de problemas es Bugzilla. Las pruebas automatizadas son NUnit

Herramientas para evitar incluir Team Foundation Server y Sharepoint, demasiado torpes para el uso en el mundo real.

BTW ¿Alguien sabe una buena herramienta de Scrum, que puede producir tablas de grabación, idealmente vinculando en Basecamp?

+0

No sé sobre el campo base, pero hay plugins trac serveral para burndown scrum que he visto durante mi investigación –

+0

Este -> http://www.agile42.com/ cms/pages/download/ – adolfojp

+0

Y esto -> http://www.sprintometer.com/ Pero ninguno de ellos se conecta al basecamp así que realmente no respondí tu pregunta. :-( – adolfojp

3

Si trabaja con .NET, es difícil vencer al Team Foundation Server para su integración con Visual Studio. Contiene las herramientas de desarrollo, control de versiones, seguimiento de problemas, administración de configuraciones, pruebas automatizadas, pruebas unitarias, construcción automatizada, gestión de artefactos y todo lo demás que ha descrito.

Por supuesto, TFS es costoso, a menudo no intuitivo y le faltan algunas características en comparación con otras herramientas que he usado. Sin embargo, si tiene una licencia de MSDN, puede usar TFS for Workgroups (hasta 5 usuarios IIRC) de forma gratuita.

0

También utilizamos una serie de herramientas, pero estamos moviéndose más y más a Zed Builds & Bugs. Nuestro entorno de desarrollo primario es Eclipse + Java, pero también hacemos Visual Studio (todos ellos) y al menos 5 compilaciones de plataforma de Unix diferentes.

Aquí está la lista completa:

0

lo uso SVN y tac en algunas uf mis proyectos y SVN y FogBugz sobre los demás. Se integran muy bien.

Todavía estoy usando scripts de línea de comandos para compilaciones, ya que hacen todo lo que necesito, incluida la compilación de errores y el envío de resultados por correo electrónico, pero los días de esa configuración están numerados. Estoy buscando herramientas de compilación multiplataforma.

Uso Inno para lanzamientos de win32. Todavía no hay productos de envío para otra plataforma, no estoy seguro de cómo los implementaremos.

No abordamos muchos de los otros elementos que menciona aparte de en algunos documentos auxiliares y en el código y en el seguimiento de problemas.

0

Team Foundation Server y Visual Studio.

Recuerdo cuando mi ide era el depurador visual C de Sun, y el control de fuente copiaba todos los archivos de origen a un nuevo directorio nombrado y lo colocaba en un servidor del que se suponía que debía hacer una copia de seguridad.

Sólo que no era

Cuestiones relacionadas