Repositorios y desarrollo troncal
Muchos científicos de datos prefieren trabajar con Python o R para definir cargas de trabajo de aprendizaje automático. Puede tener cuadernos de Jupyter Notebook o scripts para preparar datos o entrenar un modelo.
Trabajar en cualquier recurso de código resulta más fácil cuando se usa el control de código fuente. El control de código fuente es la práctica de administrar el código y realizar el seguimiento de los cambios que el equipo realice en el código.
Si trabaja con herramientas de DevOps como Azure DevOps o GitHub, el código se almacena en un repositorio o repo.
Repositorio
Al configurar el marco de MLOps, es probable que un ingeniero de aprendizaje automático cree el repositorio. Tanto si decide usar Azure Repos en repositorios de Azure DevOps o GitHub, use repositorios de Git para almacenar el código.
Por lo general, hay dos maneras de definir el ámbito del repositorio:
- Monorepo: mantenga todas las cargas de trabajo de aprendizaje automático en el mismo repositorio.
- Varios repositorios: cree un repositorio independiente para cada nuevo proyecto de aprendizaje automático.
El enfoque que prefiera el equipo depende de quién debe obtener acceso a qué recursos. Si desea garantizar el acceso rápido a todos los recursos de código, los monorepos puede adaptarse mejor a los requisitos de su equipo. Si solo quiere conceder a los usuarios acceso a un proyecto si están trabajando activamente en él, es posible que su equipo prefiera trabajar con varios repositorios. Tenga en cuenta que la administración del control de acceso puede crear más sobrecarga.
Estructure el repositorio
Sea cual sea el enfoque que tome, se recomienda acordar la estructura de carpetas de nivel superior estándar para los proyectos. Por ejemplo, puede tener las siguientes carpetas en todos los repositorios:
-
.cloud: contiene código específico de la nube, como plantillas, para crear un área de trabajo de Azure Machine Learning. -
.ad/.github: contiene Azure DevOps o artefactos de GitHub como canalizaciones YAML para automatizar flujos de trabajo. -
src: contiene cualquier código (scripts de Python o R) que se use para cargas de trabajo de aprendizaje automático, como el preprocesamiento de datos o el entrenamiento del modelo. -
docs: contiene los archivos Markdown u otra documentación usada para describir el proyecto. -
pipelines: contiene definiciones de canalizaciones de Azure Machine Learning. -
tests: contiene pruebas unitarias e de integración que se usan para detectar errores y problemas en el código. -
notebooks: contiene cuadernos de Jupyter Notebook, que se usan principalmente para la experimentación.
Nota
Los datos de entrenamiento no deben incluirse en el repositorio. Los datos se deben almacenar en una base de datos o un lago de datos. Azure Machine Learning puede tener acceso directo a una base de datos o a un lago de datos almacenando la información de conexión como almacén de datos.
Al usar una estructura estándar en todos los proyectos, los científicos de datos y otros colaboradores encontrarán más fácilmente el código en el que necesitan trabajar.
Sugerencia
Obtenga más información en Procedimientos recomendados para estructurar proyectos de ciencia de datos.
Para aprender a trabajar con repositorios como científico de datos, obtendrá información sobre el desarrollo basado en troncos.
Desarrollo troncal
La mayoría de los proyectos de desarrollo de software usan Git, que usan tanto Azure DevOps como GitHub, como sistema de control de código fuente.
La principal ventaja de usar Git es que permite la colaboración sencilla en el código y, al mismo tiempo, realizar un seguimiento de los cambios que se han hecho. Además, puede agregar portales de aprobación para asegurarse de que solo se realizarán cambios que se hayan revisado y aceptado en el código de producción.
Para lograr lo anterior, Git usa el desarrollo basado en troncos, que permite crear ramas.
El código de producción se hospeda en la rama principal. Siempre que alguien quiera realizar un cambio:
- Cree una copia completa del código de producción creando una rama.
- En la rama que creó, realizará los cambios y los probará.
- Una vez que los cambios de la rama estén listos, puede pedir a alguien que revise los cambios.
- Si se aprueban los cambios, fusionará la rama que creó con el repositorio principal y el código de producción se actualizará para reflejar los cambios.
