Git Tagging y la revisión de diseño en el desarrollo de hardware con Altium Designer

Ari Mahpour
|  Creado: July 23, 2020  |  Actualizado: September 2, 2020
 Git Tagging y la revisión de diseño en el desarrollo de hardware  con Altium Designer

El concepto de revisión en diseño electrónico ha mantenido una corriente relativamente estándar en todo el sector. Una revisión consta normalmente de una letra y contiene algunas veces un número. La gente ha probado muchos otros esquemas de revisión, pero, según mi experiencia, la revisión estándar a base de letras es la que parece prevalecer en la industria. Una pregunta que siempre me he planteado es la siguiente: ¿Qué ha pasado con todas las revisiones de diseño en medio? Entiendo que un cambio de letra significa un lanzamiento (o publicación), pero ¿qué ha pasado con todos los cambios entre esos lanzamientos? ¿Cómo se hace seguimiento de los cambios?

Con el tiempo, a esta pregunta han respondido sistemas de control de versiones, como CVS, Subversion y Git. Los desarrolladores de software probablemente estén familiarizados con el etiquetado Git tagging, pero el uso de Git para el desarrollo de hardware ofrece una manera excelente de hacer seguimiento de las revisiones, bifurcar proyectos de PCB y lanzar los proyectos. Estos sistemas de control de versiones nos dan la posibilidad de ver cada una de las distintas versiones entre lanzamientos. En el blog sobre integración y despliegue continuos en ECAD, hablábamos del concepto de lanzamiento de una nueva versión de un proyecto con cada confirmación (guardado de cambios o commit) en el repositorio. En este artículo, revisaremos una forma sencilla pero eficaz de publicar a través del servidor Git, manteniendo al mismo tiempo el vínculo con la letra de revisión de una PCB.

Etiquetado de PCB con Git

El etiquetado (tag, tagging) Git es una función que permite a los usuarios designar una confirmación específica con un fin especial. Los usuarios “etiquetan” una confirmación para indicar su lanzamiento. Por ejemplo, se podría etiquetar la tercera confirmación en el repositorio como Revisión 1.0.0 y acabar diez confirmaciones más tarde con la etiqueta Revisión 1.1.0 No hay una forma correcta o incorrecta de usar las etiquetas, pero el uso del etiquetado Git para los puntos de lanzamiento es normalmente el uso principal de esta función. 

Tanto si gestionas los proyectos en Altium Concord Pro como si lo haces en GitHub, Bitbucket, Gitlab o cualquier otra forma de servidor Git, todos ellos tienen la capacidad de etiquetar una confirmación. Algunos servidores Git tienen su propio sistema de etiquetado que se puede ejecutar desde sus interfaces web, como GitHub y Bitbucket. En otros servidores Git, puedes usar el comando git-tag desde la línea de comandos. Independientemente de cómo decidas implementar el etiquetado en Git para el desarrollo de hardware, tu equipo necesita un sistema de denominación de revisiones para que todos comprendan cómo se relacionan las diferentes versiones entre sí.

Vínculo entre un lanzamiento y una confirmación de Git

A medida que la comunidad ECAD migra hacia un sistema de control de versiones como Git, es importante mantener el vínculo entre Git y el proceso de lanzamiento con el que todos estamos familiarizados. Muchos se han esforzado por determinar la mejor manera de conservar sus confirmaciones en un sistema de control de versiones, gozando al mismo tiempo de la libertad de preparar un paquete oficial que pueda enviarse a los proveedores (o que pueda enviarse para su revisión en un momento posterior). Hay muchas maneras de abordar este tema. Lo que yo propongo es que el proceso de lanzamiento no tiene por qué ser una solución universal para todos, pero recomendaría probarlo como punto de partida y luego adaptarlo a las necesidades de cada grupo.

El principal desafío es dar sentido a todas las confirmaciones de Git y, a continuación, vincularlas a un paquete de lanzamiento. Aquí se muestra un ejemplo de una serie de confirmaciones de Git vistas en GitHub:

Git commit
Figura 1. Historial de confirmaciones del Git tagging en un repositorio de GitHub

Como puedes ver, hay muchos comentarios que describen cambios de diseño y otros comentarios que proclaman un "lanzamiento oficial". Esto es frecuente entre muchos usuarios de sistemas de control de versiones, y generalmente funciona. He visto también a usuarios que agrupan los paquetes para lanzamiento dentro del repositorio. Si bien esta puede no ser la solución más limpia (ya que contamina el repositorio con archivos que no son de diseño), parece que funciona.

En lugar de dar a conocer un lanzamiento oficial con un comentario de confirmación, podemos aprovechar el concepto de etiquetado de Git (conocido también como "lanzamientos" o releases en GitHub). En este ejemplo, hemos tomado esas confirmaciones de lanzamiento oficial y las hemos convertido en lanzamientos en GitHub (que se convierten también en etiquetas):

Release view
Figura 2. Vista de lanzamientos para repositorio de revisión de diseño en GitHub

Como se puede ver arriba, hemos tomado confirmaciones específicas y las hemos convertido en lanzamientos. GitHub anexa ahora una etiqueta a cada una de estas confirmaciones, así:

Tag view
Figura 3. Vista de etiquetas para repositorio de revisión de diseño en GitHub

Finalmente, ahora podemos buscar por lanzamiento o etiqueta en GitHub, así:

searching for tags
Figura 4. Búsqueda de etiquetas en GitHub

 

Vínculo entre un esquemático y una confirmación de Git

Otra forma de garantizar un enlace correcto entre un proyecto de PCB y el repositorio de Git es haciendo seguimiento del hash de Git en el propio esquemático. Este es un pequeño truco que John Watson me enseñó cuando usábamos Subversion. Haciendo uso de cadenas especiales, es posible vincular un esquemático (y PCB) directamente a la confirmación de Git utilizada para cargar contenido (con push) en el servidor Git. En este ejemplo, hemos colocado la cadena de control de versiones en el esquemático de nivel superior junto al bloque de título:

Git hash
Figura 5. Hash de Git utilizado como cadena especial en la revisión de diseño

Como se puede ver arriba, hay dos versiones del hash de Git representadas en el esquemático: la primera es el hash de Git completo y la segunda es la versión abreviada (como la que se usa en GitHub). Para usar la versión completa, introduje la siguiente cadena especial:

=VersionControl_ProjFolderRevNumber

Para concatenar esto al título delante, tendrías que añadir lo siguiente:

=’Git Hash:’ + VersionControl_ProjFolderRevNumberSin embargo, en el momento de escribir este artículo, descubrimos que esta cadena especial era demasiado larga para concatenarla. Una solución posible sería establecer VersionControl_ProjFolderRevNumber en un parámetro más corto. En este caso, se creó un parámetro y se estableció como VersionControl_ProjFolderRevNumber en el panel Properties para este esquemático en particular.

Redefining the Git
Figura 6. Redefinición del parámetro hash del Git tagging en el panel Properties

Ahora que hemos creado un parámetro abreviado, podemos manipular la cadena. En este caso, queremos solo los primeros 7 caracteres del hash de Git, tal como se usa en GitHub al mostrar los hashes de Git. Utilizamos la siguiente declaración de cadena especial concatenada y manipulada:

='Git Hash: ' + Copy(GitHash,1,7)

Recuerda que cualquier función de manipulación de cadenas que se utilice proviene del lenguaje Delphi. La técnica de subcadena es una simple llamada a la función Copy de Delphi integrada en la cadena de texto. Una vez que tú o tu equipo abráis los documentos de diseño desde un lanzamiento de Git en Altium Designer, podréis ver la etiqueta en esos documentos, con un enlace concreto a la revisión con control de versiones.

Implementación de Git para desarrollo de hardware en Altium 365

A medida que el sector comienza a usar revisiones en Git para el desarrollo de hardware, tanto en los entornos locales como en la nube, es importante comprender la conexión existente entre el lanzamiento oficial de un diseño de PCB y la confirmación de Git (hash) en el sistema de control de versiones. El concepto de hash de Git y el uso de esta función al publicar un proyecto de diseño de PCB dentro de un sistema de control de versiones nos permite conservar este vínculo y mantener los dos procesos (o sistemas) sincronizados.

En lugar de utilizar un sistema de control de versiones de terceros, puedes implementar Git para el desarrollo de hardware con Altium Designer y la plataforma Altium 365. Este sistema sustituye a una solución Git basada en la nube para el control de versiones y permite a tu equipo importar proyectos al instante en Altium Designer. Como alternativa, puedes implementar Altium Concord Pro en tu entorno local, lo que ofrece a tu equipo un conjunto completo de funciones para control de versiones y gestión de datos que se integran con Altium Designer.

Altium Designer en Altium 365 aporta un nivel de integración inigualable al sector de la electrónica, restringido hasta ahora al campo del desarrollo de software, permitiendo a los ingenieros trabajar desde casa y alcanzar unos niveles de eficiencia sin precedente.

Estamos solo arañando la superficie de lo que se puede lograr con Altium Designer en Altium 365. Para una descripción más a fondo, consulta la página de productos o uno de los webinars bajo demanda.

Sobre el autor / Sobre la autora

Sobre el autor / Sobre la autora

Ari is an engineer with broad experience in designing, manufacturing, testing, and integrating electrical, mechanical, and software systems. He is passionate about bringing design, verification, and test engineers together to work as a cohesive unit.

Articulos más recientes

Volver a la Pàgina de Inicio