Elegir el modelo adecuado para mantener y mejorar su proyecto de IO

| |

COMPARTE EL ARTÍCULO!!!

En el mercado actual de dispositivos embebidos conectados, impulsado por la Internet de los objetos (IO), una gran parte de los dispositivos en desarrollo se basan en Linux de una forma u otra. La prevalencia de placas de bajo coste con distribuciones de Linux ya preparadas es un factor clave en este sentido. La adquisición de hardware, la creación de código personalizado, la conexión de los dispositivos a otros periféricos de hardware e Internet, así como la gestión de dispositivos mediante proveedores comerciales de cloud computing nunca ha sido tan fácil. Un desarrollador o equipo de desarrollo puede crear rápidamente un prototipo de una nueva aplicación y poner los dispositivos en manos de usuarios potenciales. Esto es bueno y resulta en muchas aplicaciones nuevas e interesantes, así como en muchas aplicaciones cuestionables.

Cuando se planifica un diseño de sistema más allá de la fase de creación de prototipos, las cosas se vuelven un poco más complejas. En este post, queremos considerar mecanismos para desarrollar y mantener la imagen de su sistema operativo base (SO). Hay muchas herramientas para ayudar con esto, pero no discutiremos herramientas individuales; de interés aquí es el modelo subyacente para mantener y mejorar esta imagen y cómo hará que su vida mejore o empeore.

Existen dos modelos primarios para generar estas imágenes:

  1. Maestro Dorado Centralizado
  2. Sistema de construcción distribuido

Estas categorías reflejan los modelos de conducción de los sistemas de gestión de código fuente (SCM), y muchos de los argumentos relativos a los sistemas centralizados frente a los distribuidos son aplicables a la hora de hablar de las imágenes del sistema operativo.

Maestro Dorado Centralizado

Los proyectos de aficionados y fabricantes utilizan principalmente el método Centralized Golden Master para crear y mantener las imágenes de la aplicación. Este hecho le da a este modelo el beneficio de la velocidad y la familiaridad, lo que permite a los desarrolladores configurar rápidamente un sistema de este tipo y ponerlo en marcha. La velocidad proviene del hecho de que muchos fabricantes de dispositivos proporcionan imágenes enlatadas para su hardware disponible. Por ejemplo, las placas de familias como la BeagleBone y la Frambuesa Pi ofrecen imágenes y flashes de SO listos para usar. Confiar en estas imágenes significa tener su sistema listo y funcionando en sólo unos pocos clics del ratón. La familiaridad se debe al hecho de que estas imágenes se basan generalmente en una distribución de escritorio que muchos desarrolladores de dispositivos ya han utilizado, como Debian. Años de uso de Linux pueden entonces transferirse directamente al diseño incrustado, incluyendo el hecho de que las utilidades de empaquetado siguen siendo en gran medida las mismas, y es sencillo para los diseñadores obtener los paquetes de software adicionales que necesitan.

Este enfoque tiene algunas desventajas. La primera es que la imagen maestra dorada es generalmente un punto de estrangulamiento, lo que resulta en una pérdida de productividad del desarrollador después de la etapa de creación de prototipos, ya que todos deben esperar su turno para acceder a la última imagen y realizar sus cambios. En el ámbito del SCM, esta práctica equivale a un sistema centralizado con bloqueo individual de archivos. Sólo el desarrollador con el bloqueo puede trabajar en cualquier archivo.

La segunda desventaja de este enfoque es la reproducibilidad de la imagen. Este problema suele gestionarse iniciando sesión manualmente en los sistemas de destino, instalando paquetes utilizando el gestor de paquetes nativo, configurando aplicaciones y archivos de puntos y, a continuación, modificando los archivos de configuración del sistema existentes. Una vez completado este proceso, se crea una imagen del disco utilizando la utilidad dd, o una equivalente, y luego se distribuye.

Una vez más, este enfoque crea un campo minado de problemas potenciales. Por ejemplo, los feeds de paquetes basados en la red pueden dejar de existir, y el software de base proporcionado por la imagen del proveedor puede cambiar. Los scripts pueden ayudar a mitigar estos problemas. Sin embargo, estos scripts tienden a ser frágiles y se rompen cuando se realizan cambios en los formatos de los archivos de configuración o en los paquetes de software base del proveedor.

El último problema que surge con este modelo de desarrollo es la dependencia de terceros. Si los cambios de imagen del proveedor de hardware no funcionan para su diseño, es posible que tenga que invertir un tiempo considerable para adaptarse. Para complicar aún más las cosas, como se mencionó antes, los vendedores de hardware a menudo basaban sus imágenes en un proyecto ascendente como Debian o Ubuntu. Esta situación introduce aún más terceros que pueden afectar a su diseño.

Sistema de construcción distribuido

Este método de crear y mantener una imagen para su aplicación se basa en la generación de imágenes de destino separadas del hardware de destino. El flujo de trabajo del desarrollador aquí es similar al desarrollo de software estándar que utiliza un sistema SCM; la imagen se puede construir completamente con herramientas y cada desarrollador puede trabajar de forma independiente. Los cambios en el sistema se realizan a través de la edición de archivos de metadatos (scripts, recetas, archivos de configuración, etc.) y luego se vuelve a ejecutar la herramienta para generar una imagen actualizada. Estos archivos de metadatos se gestionan mediante un sistema SCM. Los desarrolladores individuales pueden fusionar los últimos cambios en sus copias de trabajo para producir sus imágenes de desarrollo. En este caso, no se necesita una imagen maestra dorada y los desarrolladores pueden evitar el cuello de botella asociado.

Las imágenes de liberación son producidas por un sistema de construcción que utiliza técnicas SCM estándar para obtener los cambios de todos los desarrolladores.

Trabajar de esta manera permite que el tamaño de su equipo de desarrollo aumente sin reducir la productividad de los desarrolladores individuales. Todos los ingenieros pueden trabajar independientemente de los demás. Además, esta configuración de compilación asegura que sus compilaciónes puedan ser reproducidas. El uso de flujos de trabajo SCM estándar puede garantizar que, en cualquier momento futuro, se pueda regenerar una construcción específica, lo que permite un mantenimiento a largo plazo, incluso si los proveedores ascendentes ya no están disponibles. Sin embargo, de forma similar al trabajo con herramientas SCM distribuidas, existe una política adicional que debe existir para permitir la reproducción de las imágenes de los candidatos. Los desarrolladores individuales tienen sus propias copias del código fuente y pueden construir sus propias imágenes de prueba, pero para un esfuerzo adecuado de ingeniería de lanzamiento, los equipos de desarrollo necesitarán establecer estándares de fusión y ramificación y asegurarse de que todos los cambios que se pretenden lanzar finalmente se fusionen en una rama bien definida. Muchos proyectos previos ya tienen procesos bien definidos para este tipo de estrategia de liberación (por ejemplo, utilizando las ramas *-estable y *-próxima).

El principal inconveniente de este enfoque es la falta de familiaridad. Por ejemplo, añadir un paquete a la imagen normalmente requiere crear una receta de algún tipo y luego actualizar las definiciones para que los binarios del paquete se incluyan en la imagen. Esto es muy diferente de ejecutar apt mientras está conectado a un sistema en ejecución. La curva de aprendizaje de estos sistemas puede ser desalentadora, pero los resultados son más predecibles y escalables, y es probable que sean una mejor opción cuando se considera un diseño para un producto que se producirá en masa.

Los sistemas de construcción dedicados como OpenEmbedded y Buildroot utilizan este modelo al igual que las herramientas de empaquetado de distro como debootstrap y multistrap. Las herramientas más nuevas como Isar, debos y ELBE también utilizan este modelo básico. Las opciones abundan, y vale la pena la inversión para aprender uno o más de estos paquetes para sus diseños. La mantenibilidad y reproducibilidad a largo plazo de estos sistemas reducirá el riesgo en su diseño al permitirle generar construcciones reproducibles, rastrear todo el código fuente y eliminar su dependencia de la existencia continua de terceros proveedores.

Conclusión

Para ser claros, el modelo distribuido sufre algunos de los mismos problemas que los mencionados para el Modelo Golden Master; especialmente la dependencia de terceros. Esto es una consecuencia del uso de sistemas diseñados por otros y no se puede evitar completamente a menos que usted elija un enfoque completamente «rodar-su-propio», el cual viene con un costo significativo en desarrollo y mantenimiento.

Para la creación de prototipos y el diseño de niveles de prueba de concepto, y un equipo de sólo unos pocos desarrolladores, el Modelo Golden Master puede ser la elección correcta dadas las restricciones de tiempo y presupuesto que están presentes en esta etapa de desarrollo. Para los diseños de bajo volumen y alto tacto, esto puede ser una compensación aceptable para el uso en la producción.

Para uso general de producción, los beneficios en términos de escalabilidad del tamaño del equipo, reproducibilidad de imágenes y productividad del desarrollador superan con creces la curva de aprendizaje y la sobrecarga de los sistemas que implementan el modelo distribuido. El apoyo de los proveedores de tarjetas y chips también está ampliamente disponible en estos sistemas, lo que reduce los costes iniciales de desarrollo con ellos. Para su próximo producto, le recomiendo encarecidamente que comience el diseño con una consideración seria del modelo que se está utilizando para generar la imagen base del sistema operativo. Si decide hacer un prototipo con el modelo maestro dorado con la intención de migrar al modelo distribuido, asegúrate de que dispone de tiempo suficiente en su agenda para este esfuerzo; las estimaciones variarán ampliamente en función de las herramientas específicas que elija, así como del alcance de los requisitos y la disponibilidad inmediata de los paquetes de software en los que se basa su código.

COMPARTE EL ARTÍCULO!!!

Previous

Casi abierto: BIOS y consejos de actualización de firmware para usuarios de Linux

Cómo usar MapTool para construir una mazmorra interactiva RPG

Next

Deja un comentario

shares