delphi - transporte - sistema kanban en ford

Configuración de un gran sistema de software en Delphi (7)

Algunos consejos:

Cree un archivo de proyecto de grupo para todas las aplicaciones que pertenecen al proyecto, cada aplicación en su propio directorio debajo del archivo groupproj
Debería poder especificar qué tipos de archivos incluir en su sistema de control de versiones. Asegúrese de configurar Delphi para escribir archivos DFM en formato de texto.
Podría decirle a Delphi que produzca DCU en los subdirectorios llamados ''dcu'' debajo de cada aplicación (menos saturación de visas).
Las cosas de terceros a menudo insisten en instalar en ubicaciones distintas, no hay mucho que puedas hacer al respecto. Haga un documento que describa cómo configurar un entorno de trabajo completo y mantenerlo actualizado.
Desarrollar en máquinas virtuales. Un nuevo desarrollador obtiene una copia de la máquina virtual.
¿Mantenimiento para diferentes versiones de Delphi? Repensar eso, tratar de ir a una versión. Si es absolutamente necesario tener dos proyectos de grupo y estructuras de directorios para cada versión. [Supongo que no estás compilando la misma aplicación con dos versiones de Delphi, eso es un infierno de desarrolladores]
Delphi XE2 dará salida a diferentes subdirectorios 32/64, que no deberían dar problemas.

Tenemos un paquete de software que tiene unos 16 años. Ha pasado por casi todas las versiones de Delphi (además de las de .NET). A lo largo de los años, las cosas se han vuelto muy confusas cuando se trata de hacer referencias cruzadas y mantener una configuración adecuada para paquetes adicionales (como bibliotecas de terceros). Me preguntaba si existe alguna práctica estándar cuando se trata de organizar grandes proyectos (y grupos de proyectos) como este.

Así que para explicar la configuración actual ...

Este es un sistema multi-aplicación. Es decir, hay 12 proyectos ejecutables (y algunos proyectos de DLL y servicio) involucrados. También mantenemos las cosas en SourceSafe y varios desarrolladores trabajan en el mismo código en diferentes computadoras. Todos estos proyectos son volcados en una carpeta central. La carpeta "Root" contiene el proyecto principal de EXE (junto con unas 20 carpetas, todas con unidades y formularios) y casi parece una jerarquía sin fin de carpetas y archivos. Este proyecto solo tiene medio millón de líneas de código involucrado.

Entonces, todas las aplicaciones adicionales no están necesariamente separadas de este gran proyecto. Cada uno de estos proyectos tiene su propia carpeta basada en la raíz del proyecto principal.

Las dos principales preocupaciones de la mía son:

¿Cómo configurar correctamente los archivos DCU para que no se mezclen con los proyectos? Los DCU NO deben colocarse en SourceSafe (y cualquier otro archivo similar), o de lo contrario, en ningún archivo compilado del proyecto. Visual SourceSafe hace que los archivos sean de solo lectura cuando no están protegidos, y los archivos DCU (y los archivos EXE y más) no se pueden escribir en este caso. Entonces, ¿cómo separar correctamente cualquiera de dichos archivos en una ubicación remota para evitar cualquier mezcla con el código fuente?
¿Cómo configurar correctamente los paquetes y bibliotecas? Tenemos los siguientes:
- Informes rápidos 5.05
- Biblioteca NativeJpg V302 -
- Otra biblioteca de informes anónimos
- Nuestro propio paquete de componentes, que requiere QuickReports, NativeJpg y la otra biblioteca anónima

Las 4 bibliotecas se almacenan en lugares completamente diferentes de cada computadora y necesitan cierta centralización. El mayor inconveniente de configurar la computadora de cada nuevo desarrollador es ubicarlos en la computadora del desarrollador principal y copiarlos en el mismo lugar en cada computadora (y asegurarse de que la ruta de la biblioteca sea correcta, etc.).

También necesitamos mantener entornos completamente separados para diferentes versiones de Delphi en la misma computadora. Esto significa una copia de los proyectos en cada computadora, una copia de los paquetes y bibliotecas en cada computadora, una copia de los proyectos y paquetes y bibliotecas en SourceSafe, etc. Cada computadora debe tener una configuración idéntica. Ya utilizamos variables de entorno para dirigir nuestros proyectos donde buscar ciertos archivos de proyecto (y bibliotecas).

Otra nueva preocupación: XE2 introduce capacidades de 64 bits. Aún no planeamos compilar a 64 bits, pero lo haremos en el futuro. ¿Cómo puedo diferenciar adecuadamente 32 bits de 64 bits en todos estos proyectos?

Lo que realmente estoy pidiendo es una referencia a un buen tutorial sobre cómo optimizar dicho entorno y mantenerlo organizado de la mejor manera. No espero que nadie se tome el tiempo y responda todo esto en la pregunta. Los proyectos tienen más de 15 años, han estado en manos de más de 200 desarrolladores de todo el mundo y tienen MUCHAS referencias cruzadas entre proyectos. Por ejemplo, un proyecto puede usar una unidad de otro proyecto, y viceversa. Personalmente no me gusta este concepto, pero tampoco lo diseñé para empezar. Me han encomendado la tarea de organizar este sistema y documentar detalladamente cómo configurar Delphi en una computadora nueva para que los nuevos desarrolladores trabajen en nuestros proyectos. Mientras miro nuestros proyectos (ya que no soy necesariamente un desarrollador del sistema, pero estoy siendo puesto en desarrollo), estoy viendo mucha confusión en la forma en que se organiza el código.

Estoy asumiendo que posiblemente Embarcadero tenga algunas pautas y estándares para establecer un entorno de este tipo.

Fuera del ámbito que fue discutido en gran medida antes, recomendaría:

Pruebas unitarias - con DUnit por ejemplo
Integración continua . Solo para asegurarnos de que todos estos proyectos se puedan compilar en otra máquina y que las pruebas estén bien.

Así que esto está fuertemente relacionado con la organización del proyecto y la estrategia VCS.

Me dirigiré a la organización de carpetas. Esto viene de una suite de software que tiene más de 50 exe y dll''s y muchas bibliotecas de terceros, así que supongo que sé de dónde vienes ...

Utilizamos Perforce como sistema de control de origen, por lo que la carpeta raíz de mi área de trabajo predeterminada se llama Perforce, pero también tengo un par de otras áreas de trabajo configuradas y están en Perforce2, Perforce3, etc.

Configuración general de la carpeta (a partir de la carpeta raíz del área de trabajo)

General Components Delphi Indy Indy9 Indy10 MadCollection v2.5.8.0 v2.6.0.0 Plugins Releases Released ... a folder for each release we publish ... (and equal to a branch in Perforce) Work Acceptance Sub1 Sub2

La ruta de la biblioteca de Mi entorno en el IDE está vacía (ni siquiera las rutas estándar de BDE están ahí). Esto garantiza que las rutas de un proyecto declaren todas las rutas necesarias y que los proyectos no dependan de la configuración IDE de una máquina en particular.

Tenemos un entorno var (es decir, MRJ) configurado en nuestro IDE que apunta a "General / Componentes / Delphi", por lo que en las opciones de un proyecto declaramos las rutas a nuestros componentes como $(MRJ)/MadCollection/2.6.0.0 .

General posee complementos y componentes IDE utilizados por nuestros proyectos. Mantenemos todas las versiones que usamos en control de código fuente. De esa manera, cuando tengo que volver a una versión anterior para rastrear un problema, simplemente puedo extraerlo y compilarlo ya que las rutas de la biblioteca seguirán apuntando a la versión de los componentes que necesita esta versión específica.

La organización de carpetas en una rama de trabajo particular (Aceptación o una de sus subramas) sigue este patrón:

General Includes MainComponent1 Project1 Project2 Shared MainComponent2 Project3 Project4 Shared Shared Windows SoftwareSuite Scripts Tools MainComponent1 Project1 Dcus Project2 Dcus MainComponent2 Tools Tool1 Dcus Tool2 Dcus

La carpeta General contiene todas las fuentes / archivos independientes de la plataforma, la carpeta de Windows contiene todos los archivos específicos de Windows. Cada componente puede contener múltiples proyectos y tendrá una carpeta compartida para las fuentes compartidas entre esos proyectos. La carpeta compartida directamente en General contiene las fuentes compartidas por todos los proyectos. La carpeta de Windows está configurada de manera similar.

Tenga en cuenta que cada proyecto tiene su propia carpeta dcus . Esto se configura en las opciones del proyecto. Como la ruta se puede ingresar como .dcus , nosotros (al menos yo) tenemos esta configuración predeterminada para cualquier proyecto nuevo. Cada proyecto que envía su disco a una carpeta única garantiza dos cosas:

es fácil mantener a Dcu''s fuera del control de versiones simplemente configurando un filtro en su software de control de versiones.
lo más importante es que garantiza que la compilación / construcción de un proyecto nunca interfiera con la compilación / construcción de otro proyecto. Puedo cambiar la configuración y construir de manera segura sabiendo que no me molestarán los dcu que se encuentran en una compilación anterior de otro proyecto.

Mi equipo utiliza la virtualización y, cuando vemos de nuevo, fue un movimiento realmente bueno. Utilizamos computadoras portátiles MacBook Pro y VmWare Fusion, pero estoy seguro de que otros paquetes funcionan bien como VirtualBox o VirtualPC.

Siempre es una buena sensación saber que cuando un nuevo desarrollador se inicia o una instalación anterior tiene problemas, es simplemente copiar una nueva imagen de máquina virtual desde la imagen maestra y la configuración es exactamente igual a la original. La imagen maestra se almacena en un disco USB2 rápido. Ahora, cuando vengan Thunderbolt y USB3, sería aún más rápido copiar una imagen. Y no hay una preocupación real por el rendimiento en una computadora moderna mientras haya memoria. 8 GB debería ser suficiente para ejecutar 2 imágenes en paralelo. Otra ventaja de la virtualización es que es muy fácil probar el escenario What if . Experimente con diferentes configuraciones y versiones sin ningún riesgo para perturbar el entorno de trabajo real.

Por cierto, también creo que SourceSafe es una mierda ... :-)

Para una configuración similar, una empresa para la que trabajé encontró útil esta configuración:

todas las bibliotecas de terceros (componentes, etc.) van a una ubicación fija (C: / Delphi / name-version)
Los proyectos de Delphi se pueden retirar del control de versiones en cualquier lugar (la unidad C: o D: y el nombre de la carpeta no son importantes), ya que todos los proyectos y scripts utilizan rutas relativas
todos los proyectos son subcarpetas de una carpeta principal de proyectos, por lo que al revisar esto se incluirán los proyectos Delphi y otros recursos relevantes para la estación de trabajo, y es fácil realizar una actualización de control de versión
usamos un script de compilación (escrito en Apache Ant) que se encuentra en la carpeta principal, y recorre todas las carpetas para compilar las aplicaciones Delphi y ejecutar las pruebas de unidad e integración en un servidor de base de datos de desarrollo, para verificar que todos los cambios funcionan antes de ingresar a la fuente controlar
El script de compilación también se puede ejecutar automáticamente en un servidor de compilación (Hudson CI) en cada confirmación para ver si algo se rompió

Y una nota sobre las bibliotecas de componentes: evite la instalación de paquetes cuando sea posible, prefiera la creación de componentes en tiempo de ejecución. Si rápidamente necesita aplicar una solución a una versión de cinco años de un proyecto, la desinstalación / instalación de una docena de paquetes puede resultar frustrante. Al menos para los componentes no visuales, la creación en tiempo de ejecución es un gran ahorro de tiempo.

Verificar el código de un tercero en el control de código fuente puede ser muy útil, por ejemplo, para compartir arreglos que aún no están disponibles como nuevas versiones oficiales. Las mejores prácticas se tratan en el capítulo de documentación de Subversion Ramas de proveedores . Además, con Subversion puede usar svn: externals para colocar una versión específica (etiqueta) directamente en la estructura de directorio de un proyecto. Esto se puede usar tanto con la biblioteca de terceros como con su propio código fuente, y facilita la administración de dependencias y facilita la configuración de la estación de trabajo.

ps el script de compilación de Ant define las rutas de búsqueda para todo, por lo que es ''la referencia'' para todos los desarrolladores cómo configurar el IDE, dónde colocar las librerías de terceros y qué indicadores del compilador utilizar

pps su proyecto suena muy divertido, estoy abierto para trabajar por contrato :)

Recomiendo las siguientes prácticas:

Mantenga la ruta de la biblioteca simple y asegúrese de que toda la ruta de la biblioteca sea una carpeta que se envíe con Delphi o una carpeta binaria (biblioteca) de DCU en su carpeta d: / Components /.
Utilice un tipo de control de versión MODERNO. Recomiendo Mercurial sobre otros. Source Safe es una mierda, deja de usarlo.
Realice una copia de seguridad de su entorno (exporte las claves de registro, etc.) y restáurelo a las otras PC de desarrollador de forma estandarizada. Puede mantener algunos archivos .reg y .cmd (por lotes) para automatizar la configuración de un nuevo sistema. puede poner estos scripts en su repositorio de componentes en su sistema de control de versiones.

Ubicación de los archivos DCU

Con respecto a las DCU que son el resultado del proceso de compilación, debe especificar un directorio de salida de DCU en cada archivo de proyecto. El valor predeterminado para esto, en la última versión de Delphi, estaría bien:. ./$(Platform)/$(Config) . Esto da como resultado subcarpetas del directorio del proyecto como este: Win32/DEBUG o Win64/RELEASE .

Si configura sus archivos de proyecto utilizando conjuntos de opciones, entonces podrá controlar esta configuración (y todas las demás) desde una pequeña cantidad de archivos de opciones.

Ubicación del código de terceros

Siempre debe utilizar la biblioteca de terceros como código. Si el proveedor cobra más por recibir la biblioteca como código, pague. Una vez que lo haya hecho, simplemente incluya el código fuente en su sistema de control de versiones (VCS) y lo tratará en gran medida de la misma manera que trata su propio código. Digo en gran parte porque debes evitar modificarlo.

Una vez que tenga todo su código en el VCS, puede colocar el código fuente completo en una máquina nueva con una sola operación de pago.

Organización de tus proyectos.

Personalmente tengo una fuerte aversión al uso de las rutas de búsqueda del compilador. No los uso e incluyo todas las unidades que se requieren en un proyecto en el archivo .dpr.

Si usa rutas de búsqueda, entonces es imposible trabajar en proyectos de variantes. Por ejemplo, supongamos que tiene un cliente que ha descubierto un error en la versión del software que lanzó hace 2 años. Le gustaría solucionar ese error lanzando una actualización a la versión de 2 años del software. Es perfectamente plausible que pedirles que actualicen a la última versión no es viable. Quizás no hayan pagado las mejoras. Tal vez la actualización completa tenga cambios de última hora que no quieren abordar en este momento. Un ejemplo perfecto sería todos los desarrolladores de Delphi que todavía utilizan Delphi 7.

Ahora, habiendo motivado el escenario, ¿cómo crearía un entorno de construcción para el proyecto de 2 años? Si está utilizando rutas de búsqueda, se referirán a las bibliotecas de hoy. Se vería obligado a cambiar su ruta de búsqueda, o copiar las bibliotecas antiguas sobre la parte superior de las bibliotecas de hoy.

Todo el dolor de cabeza es trivialmente evitado al no usar rutas de búsqueda e incluir toda su fuente en el VCS.

Lo que debe apuntar es poder verificar cualquier versión histórica de su programa y hacer que se construya de inmediato. Debería poder hacer esto con plena confianza de que está creando un software idéntico al que se creó en el momento en que se lanzó esa versión. Esto también requiere que tengas automatización de compilación, pero no puedo imaginar que te falte eso para un proyecto de este tamaño.