Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Mejores prácticas para la estructura y organización de la base de código
La estructura y la organización adecuadas de la base de código son fundamentales a medida que el uso de Terraform crece en grandes equipos y empresas. Una base de código bien diseñada permite la colaboración a escala y, al mismo tiempo, mejora la capacidad de mantenimiento.
Esta sección proporciona recomendaciones sobre la modularidad de Terraform, las convenciones de nomenclatura, la documentación y los estándares de codificación que respaldan la calidad y la coherencia.
Las directrices incluyen dividir la configuración en módulos reutilizables por entorno y componentes, establecer convenciones de nomenclatura mediante el uso de prefijos y sufijos, documentar los módulos y explicar con claridad las entradas y salidas, y aplicar reglas de formato coherentes mediante comprobaciones de estilo automatizadas.
Otras buenas prácticas incluyen la organización lógica de los módulos y recursos en una jerarquía estructurada, la catalogación de los módulos públicos y privados en la documentación y la abstracción de los detalles de implementación innecesarios en los módulos para simplificar el uso.
Al implementar pautas de estructura de código base en torno a la modularidad, la documentación, los estándares y la organización lógica, puede respaldar una amplia colaboración entre los equipos y, al mismo tiempo, mantener Terraform mantenible a medida que el uso se extiende por toda la organización. Al aplicar las convenciones y los estándares, puede evitar la complejidad de una base de código fragmentada.
Mejores prácticas:
Implemente una estructura de repositorio estándar
Se recomienda implementar el siguiente diseño de repositorio. La estandarización de estas prácticas de coherencia en todos los módulos mejora la capacidad de descubrimiento, la transparencia, la organización y la confiabilidad, al tiempo que permite la reutilización en muchas configuraciones de Terraform.
-
Módulo o directorio raíz: este debería ser el punto de entrada principal tanto para los módulos raíz
como para los reutilizables de Terraform y se espera que sea único. Si tienes una arquitectura más compleja, puedes usar módulos anidados para crear abstracciones ligeras. Esto le ayuda a describir la infraestructura en términos de su arquitectura en lugar de hacerlo directamente, en términos de objetos físicos. -
README: el módulo raíz y cualquier módulo anidado deben tener archivos README. Este archivo debe tener un nombre.
README.md
Debe contener una descripción del módulo y para qué se debe utilizar. Si desea incluir un ejemplo del uso de este módulo con otros recursos, colóquelo en unexamples
directorio. Considere la posibilidad de incluir un diagrama que describa los recursos de infraestructura que el módulo podría crear y sus relaciones. Utilice terraform-docspara generar automáticamente entradas o salidas del módulo. -
main.tf: Este es el punto de entrada principal. Para un módulo simple, todos los recursos pueden crearse en este archivo. En el caso de un módulo complejo, la creación de recursos puede estar distribuida en varios archivos, pero cualquier llamada a un módulo anidado debería estar en el
main.tf
archivo. -
variables.tf y outputs.tf: estos archivos contienen las declaraciones de las variables y las salidas. Todas las variables y salidas deben tener descripciones de una o dos oraciones que expliquen su propósito. Estas descripciones se utilizan como documentación. Para obtener más información, consulte la HashiCorp documentación sobre la configuración de variables
y la configuración de salida . -
Todas las variables deben tener un tipo definido.
-
La declaración de variables también puede incluir un argumento predeterminado. Si la declaración incluye un argumento predeterminado, la variable se considera opcional y se utiliza el valor predeterminado si no se establece un valor al llamar al módulo o ejecutar Terraform. El argumento predeterminado requiere un valor literal y no puede hacer referencia a otros objetos de la configuración. Para hacer que una variable sea obligatoria, omita un valor predeterminado en la declaración de la variable y considere si la configuración tiene
nullable = false
sentido. -
Para las variables que tienen valores independientes del entorno (por ejemplo,
disk_size
), proporcione los valores predeterminados. -
En el caso de las variables que tienen valores específicos del entorno (por ejemplo,
project_id
), no proporciones valores predeterminados. En este caso, el módulo de llamada debe proporcionar valores significativos. -
Utilice valores predeterminados vacíos para variables como cadenas o listas vacías solo cuando dejar la variable vacía sea una preferencia válida que las API subyacentes no rechacen.
-
Sea prudente al usar las variables. Parametrice los valores solo si deben variar para cada instancia o entorno. Cuando decida si desea exponer una variable, asegúrese de contar con un caso de uso concreto para cambiarla. Si existe una pequeña posibilidad de que se necesite una variable, no la expongas.
-
Añadir una variable con un valor predeterminado es compatible con versiones anteriores.
-
La eliminación de una variable no es compatible con versiones anteriores.
-
En los casos en los que un literal se reutilice en varios lugares, debe utilizar un valor local sin exponerlo como una variable.
-
-
No pases los resultados directamente a través de las variables de entrada, ya que al hacerlo evitarás que se agreguen correctamente a la gráfica de dependencias. Para garantizar que se creen dependencias implícitas
, asegúrese de que las salidas hagan referencia a los atributos de los recursos. En lugar de hacer referencia directamente a una variable de entrada para una instancia, pasa el atributo.
-
-
locals.tf: este archivo contiene valores locales que asignan un nombre a una expresión, por lo que un nombre se puede usar varias veces dentro de un módulo en lugar de repetir la expresión. Los valores locales son como las variables locales temporales de una función. Las expresiones de los valores locales no se limitan a constantes literales; también pueden hacer referencia a otros valores del módulo, como variables, atributos de recursos u otros valores locales, para combinarlos.
-
providers.tf: este archivo contiene el bloque terraform y los bloques provider
. provider
Los consumidores de los módulos deben declarar los bloques únicamente en los módulos raíz.Si utilizas HCP Terraform, añade también un bloque de nube
vacío. El cloud
bloque debe configurarse completamente mediante variables de entorno y credenciales de variablesde entorno como parte de una canalización de CI/CD. -
versions.tf: este archivo contiene el bloque required_providers.
Todos los módulos de Terraform deben declarar qué proveedores requieren para que Terraform pueda instalar y usar estos proveedores. -
data.tf: Para una configuración sencilla, coloque las fuentes de datos
junto a los recursos que hacen referencia a ellas. Por ejemplo, si vas a buscar una imagen para usarla al lanzar una instancia, colócala junto a la instancia en lugar de recopilar los recursos de datos en su propio archivo. Si el número de fuentes de datos es demasiado grande, plantéate moverlos a un data.tf
archivo dedicado. -
Archivos.tfvars: en el caso de los módulos raíz, puede proporcionar variables no sensibles mediante un archivo.
.tfvars
Para mantener la coherencia, asigne un nombre a los archivos de variables.terraform.tfvars
Coloque los valores comunes en la raíz del repositorio y los valores específicos del entorno en laenvs/
carpeta. -
Módulos anidados: los módulos anidados deben estar en el subdirectorio.
modules/
Cualquier módulo anidado que tenga unREADME.md
se considera utilizable por un usuario externo. SiREADME.md
no existe, el módulo se considera únicamente para uso interno. Los módulos anidados deben usarse para dividir el comportamiento complejo en varios módulos pequeños que los usuarios puedan elegir cuidadosamente.Si el módulo raíz incluye llamadas a módulos anidados, estas llamadas deben utilizar rutas relativas, por ejemplo,
./modules/sample-module
para que Terraform las considere parte del mismo repositorio o paquete en lugar de volver a descargarlas por separado.Si un repositorio o paquete contiene varios módulos anidados, lo ideal sería que la persona que los llamara pudiera componerlos en lugar de llamarse directamente entre sí y crear un árbol de módulos muy anidado.
-
Ejemplos: deberían existir ejemplos del uso de un módulo reutilizable en el
examples/
subdirectorio de la raíz del repositorio. Para cada ejemplo, puedes añadir un archivo README para explicar el objetivo y el uso del ejemplo. Los ejemplos de submódulos también deben colocarse en el directorio raízexamples/
.Como los ejemplos suelen copiarse en otros repositorios para su personalización, los bloques de módulos deben tener su origen establecido en la dirección que utilizaría una persona externa, no en una ruta relativa.
-
Archivos con nombres de servicio: los usuarios suelen querer separar los recursos de Terraform por servicio en varios archivos. Esta práctica debe desalentarse en la medida de lo posible y, en
main.tf
su lugar, deberían definirse los recursos. Sin embargo, si un conjunto de recursos (por ejemplo, las funciones y políticas de IAM) supera las 150 líneas, es razonable dividirlo en sus propios archivos, por ejemplo.iam.tf
De lo contrario, todo el código de recursos debería estar definido en.main.tf
-
Secuencias de comandos personalizadas: utilice las secuencias de comandos solo cuando sea necesario. Terraform no tiene en cuenta ni administra el estado de los recursos que se crean mediante scripts. Utilice scripts personalizados solo cuando los recursos de Terraform no admitan el comportamiento deseado. Coloque los scripts personalizados invocados por Terraform en un
scripts/
directorio. -
Secuencias de comandos auxiliares: Organice las secuencias de comandos auxiliares a las que Terraform no haya llamado en un directorio.
helpers/
Documente los scripts auxiliares en elREADME.md
archivo con explicaciones y ejemplos de invocaciones. Si los scripts auxiliares aceptan argumentos, proporcione la comprobación y el resultado de los argumentos.--help
-
Archivos estáticos: los archivos estáticos a los que Terraform hace referencia pero que no ejecuta (como los scripts de inicio cargados en instancias de EC2) deben organizarse en un directorio.
files/
Coloca los documentos extensos en archivos externos, separados de su HCL. Haga referencia a ellos con la función file (). -
Plantillas: para los archivos que lee la función templatefile
de Terraform, utilice la extensión de archivo. .tftpl
Las plantillas deben colocarse en un directorio.templates/
Estructura del módulo raíz
Terraform siempre se ejecuta en el contexto de un único módulo raíz. Una configuración completa de Terraform consta de un módulo raíz y un árbol de módulos secundarios (que incluye los módulos a los que llama el módulo raíz, cualquier módulo llamado por esos módulos, etc.).
Ejemplo básico del diseño del módulo raíz de Terraform:
. ├── data.tf ├── envs │ ├── dev │ │ └── terraform.tfvars │ ├── prod │ │ └── terraform.tfvars │ └── test │ └── terraform.tfvars ├── locals.tf ├── main.tf ├── outputs.tf ├── providers.tf ├── README.md ├── terraform.tfvars ├── variables.tf └── versions.tf
Estructura de módulo reutilizable
Los módulos reutilizables siguen los mismos conceptos que los módulos raíz. Para definir un módulo, cree un nuevo directorio para él y coloque los .tf
archivos en su interior, del mismo modo que definiría un módulo raíz. Terraform puede cargar módulos desde rutas relativas locales o desde repositorios remotos. Si espera que un módulo se reutilice en muchas configuraciones, colóquelo en su propio repositorio de control de versiones. Es importante mantener el árbol de módulos relativamente plano para que sea más fácil reutilizar los módulos en diferentes combinaciones.
Ejemplo básico de diseño de módulos reutilizables de Terraform:
. ├── data.tf ├── examples │ ├── multi-az-new-vpc │ │ ├── data.tf │ │ ├── locals.tf │ │ ├── main.tf │ │ ├── outputs.tf │ │ ├── providers.tf │ │ ├── README.md │ │ ├── terraform.tfvars │ │ ├── variables.tf │ │ ├── versions.tf │ │ └── vpc.tf │ └── single-az-existing-vpc │ │ ├── data.tf │ │ ├── locals.tf │ │ ├── main.tf │ │ ├── outputs.tf │ │ ├── providers.tf │ │ ├── README.md │ │ ├── terraform.tfvars │ │ ├── variables.tf │ │ └── versions.tf ├── iam.tf ├── locals.tf ├── main.tf ├── outputs.tf ├── README.md ├── variables.tf └── versions.tf
Estructura de modularidad
En principio, puede combinar cualquier recurso y otras construcciones en un módulo, pero el uso excesivo de módulos anidados y reutilizables puede hacer que la configuración general de Terraform sea más difícil de entender y mantener, por lo que debe utilizar estos módulos con moderación.
Cuando tenga sentido, divida su configuración en módulos reutilizables que aumenten el nivel de abstracción. Para ello, describa un nuevo concepto de su arquitectura que se construya a partir de tipos de recursos.
Al modular la infraestructura en definiciones reutilizables, opte por conjuntos lógicos de recursos en lugar de componentes individuales o colecciones demasiado complejas.
No agrupe recursos individuales
No debes crear módulos que sean envoltorios delgados alrededor de otros tipos de recursos únicos. Si tienes problemas para encontrar un nombre para tu módulo que sea diferente del nombre del tipo de recurso principal que contiene, es probable que tu módulo no esté creando una nueva abstracción, sino que esté añadiendo complejidad innecesaria. En su lugar, usa el tipo de recurso directamente en el módulo de llamada.
Encapsula las relaciones lógicas
Agrupe conjuntos de recursos relacionados, como los fundamentos de las redes, los niveles de datos, los controles de seguridad y las aplicaciones. Un módulo reutilizable debe encapsular las partes de la infraestructura que funcionan juntas para habilitar una capacidad.
Mantenga la herencia estable
Cuando anide módulos en subdirectorios, evite profundizar más de uno o dos niveles. Las estructuras de herencia profundamente anidadas complican las configuraciones y la solución de problemas. Los módulos deben basarse en otros módulos, no construir túneles a través de ellos.
Al centrar los módulos en agrupaciones de recursos lógicos que representan patrones de arquitectura, los equipos pueden configurar rápidamente bases de infraestructura confiables. Equilibre la abstracción sin sobreingeniería ni simplificación excesivas.
Recursos de referencia en los productos
Para cada recurso que se defina en un módulo reutilizable, incluya al menos un resultado que haga referencia al recurso. Las variables y los resultados permiten inferir las dependencias entre los módulos y los recursos. Sin ningún resultado, los usuarios no pueden ordenar correctamente su módulo en relación con sus configuraciones de Terraform.
Los módulos bien estructurados que proporcionan la coherencia del entorno, las agrupaciones con objetivos específicos y las referencias de recursos exportadas permiten la colaboración a escala de Terraform en toda la organización. Los equipos pueden armar la infraestructura a partir de componentes reutilizables.
No configure los proveedores
Si bien los módulos compartidos heredan los proveedores de los módulos de llamada, los módulos no deberían configurar los ajustes del proveedor por sí mismos. Evite especificar bloques de configuración del proveedor en los módulos. Esta configuración solo debe declararse una vez a nivel mundial.
Declare los proveedores obligatorios
Si bien las configuraciones de los proveedores se comparten entre los módulos, los módulos compartidos también deben declarar sus propios requisitos de proveedor
Al declarar los requisitos de versión y evitar la configuración de proveedores codificada, los módulos proporcionan portabilidad y reutilización en todas las configuraciones de Terraform que utilizan proveedores compartidos.
Para declarar que un módulo requiere una versión determinada del AWS proveedor, usa un required_providers
bloque dentro de un bloque: terraform
terraform { required_version = ">= 1.0.0" required_providers { aws = { source = "hashicorp/aws" version = ">= 4.0.0" } } }
Si un módulo compartido solo admite una versión específica del AWS proveedor, utilice el operador de restricción pesimista (~>
), que permite que solo se incremente el componente de la versión que se encuentra más a la derecha:
terraform { required_version = ">= 1.0.0" required_providers { aws = { source = "hashicorp/aws" version = "~> 4.0" } } }
En este ejemplo, ~> 4.0
permite la instalación de y, pero no. 4.57.1
4.67.0
5.0.0
Para obtener más información, consulte Sintaxis de restricciones de versión
Siga las convenciones de nomenclatura
Los nombres descriptivos y claros simplifican la comprensión de las relaciones entre los recursos del módulo y el propósito de los valores de configuración. La coherencia con las pautas de estilo mejora la legibilidad tanto para los usuarios como para los encargados del mantenimiento del módulo.
Siga las pautas para la denominación de los recursos
-
Usa snake_case (donde los términos en minúscula están separados por guiones bajos) en todos los nombres de los recursos para que coincidan con los estándares de estilo de Terraform. Esta práctica garantiza la coherencia con la convención de nomenclatura para los tipos de recursos, los tipos de fuentes de datos y otros valores predefinidos. Esta convención no se aplica a los argumentos de los nombres
. -
Para simplificar las referencias a un recurso que es el único de su tipo (por ejemplo, un único balanceador de carga para todo un módulo), asigne un nombre al recurso
main
othis
para mayor claridad. -
Usa nombres significativos que describan el propósito y el contexto del recurso y que ayuden a diferenciar recursos similares (por ejemplo, para la base de datos principal y
primary
read_replica
para una réplica de lectura de la base de datos). -
Use nombres en singular, no en plural.
-
No repitas el tipo de recurso en el nombre del recurso.
Siga las pautas para la denominación de las variables
-
Agregue unidades a los nombres de las entradas, variables locales y salidas que representen valores numéricos como el tamaño del disco o el tamaño de la RAM (por ejemplo,
ram_size_gb
para el tamaño de la RAM en gigabytes). Esta práctica aclara la unidad de entrada esperada para los responsables del mantenimiento de la configuración. -
Utilice unidades binarias como MiB y GiB para los tamaños de almacenamiento y unidades decimales como MB o GB para otras métricas.
-
Asigne a las variables booleanas nombres positivos como.
enable_external_access
Utilice los recursos de archivos adjuntos
Algunos recursos tienen pseudorecursos integrados como atributos. Siempre que sea posible, debes evitar el uso de estos atributos de recursos integrados y, en su lugar, usar el recurso único para adjuntar ese pseudorecurso. Estas relaciones de recursos pueden provocar cause-and-effect problemas exclusivos para cada recurso.
Uso de un atributo incrustado (evite este patrón):
resource "aws_security_group" "allow_tls" { ... ingress { description = "TLS from VPC" from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = [aws_vpc.main.cidr_block] ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block] } egress { from_port = 0 to_port = 0 protocol = "-1" cidr_blocks = ["0.0.0.0/0"] ipv6_cidr_blocks = ["::/0"] } }
Uso de recursos de archivos adjuntos (preferido):
resource "aws_security_group" "allow_tls" { ... } resource "aws_security_group_rule" "example" { type = "ingress" description = "TLS from VPC" from_port = 443 to_port = 443 protocol = "tcp" cidr_blocks = [aws_vpc.main.cidr_block] ipv6_cidr_blocks = [aws_vpc.main.ipv6_cidr_block] security_group_id = aws_security_group.allow_tls.id }
Usa etiquetas predeterminadas
Asigne etiquetas a todos los recursos que puedan aceptarlas. El AWS proveedor de Terraform tiene una fuente de datos aws_default_tags
Considere agregar las etiquetas necesarias a todos los recursos creados por un módulo de Terraform. Esta es una lista de posibles etiquetas para adjuntar:
-
Nombre: nombre del recurso legible por humanos
-
AppId: el ID de la aplicación que usa el recurso
-
AppRole: la función técnica del recurso; por ejemplo, «servidor web» o «base de datos»
-
AppPurpose: El propósito comercial del recurso; por ejemplo, «interfaz de usuario» o «procesador de pagos»
-
Entorno: el entorno de software, como desarrollo, prueba o producción
-
Proyecto: los proyectos que utilizan el recurso
-
CostCenter: ¿A quién facturar por el uso de los recursos
Cumple con los requisitos de registro de Terraform
Un repositorio de módulos debe cumplir todos los requisitos siguientes para poder publicarse en un registro de Terraform.
Siempre debe seguir estos requisitos, incluso si no planea publicar el módulo en un registro a corto plazo. De este modo, puede publicar el módulo en un registro más adelante sin tener que cambiar la configuración y la estructura del repositorio.
-
Nombre del repositorio: en el caso de un repositorio de módulos, utilice el nombre dividido en tres partes
terraform-aws-<NAME>
, donde se<NAME>
refleje el tipo de infraestructura que administra el módulo. El<NAME>
segmento puede contener guiones adicionales (por ejemplo,).terraform-aws-iam-terraform-roles
-
Estructura de módulos estándar: el módulo debe cumplir con la estructura de repositorio estándar. Esto permite que el registro inspeccione el módulo y genere documentación, realice un seguimiento del uso de los recursos y mucho más.
-
Tras crear el repositorio de Git, copia los archivos del módulo en la raíz del repositorio. Te recomendamos que coloques cada módulo que vaya a ser reutilizable en la raíz de su propio repositorio, pero también puedes hacer referencia a los módulos de los subdirectorios.
-
Si utilizas HCP Terraform, publica los módulos que quieres compartir en el registro de tu organización. El registro gestiona las descargas y controla el acceso con los tokens de la API de HCP Terraform, por lo que los consumidores no necesitan acceder al repositorio fuente del módulo incluso cuando ejecutan Terraform desde la línea de comandos.
-
-
Ubicación y permisos: el repositorio debe estar en uno de sus proveedores de sistemas de control de versiones (VCS)
configurados y la cuenta de usuario del VCS de HCP Terraform debe tener acceso de administrador al repositorio. El registro necesita acceso de administrador para crear los webhooks e importar nuevas versiones de los módulos. -
Etiquetas x.y.z para las versiones: debe haber al menos una etiqueta de publicación para poder publicar un módulo. El registro utiliza etiquetas de publicación para identificar las versiones de los módulos. Los nombres de las etiquetas de publicación deben utilizar un control de versiones semántico
, al que, si lo desea, puede añadir como prefijo un v
(por ejemplo,v1.1.0
y).1.1.0
El registro ignora las etiquetas que no se parecen a los números de versión. Para obtener más información sobre la publicación de módulos, consulte la documentación de Terraform.
Para obtener más información, consulte Preparación de un repositorio de módulos
Utilice las fuentes de módulos recomendadas
Terraform usa el source
argumento de un bloque de módulos para buscar y descargar el código fuente de un módulo secundario.
Le recomendamos que utilice rutas locales para los módulos estrechamente relacionados que tengan como objetivo principal descartar los elementos de código repetidos, y que utilice un registro de módulos nativo de Terraform o un proveedor de VCS para los módulos que estén destinados a ser compartidos por varias configuraciones.
Los siguientes ejemplos ilustran los tipos de fuentes
Registro
Registro de Terraform:
module "lambda" { source = "github.com/terraform-aws-modules/terraform-aws-lambda.git?ref=e78cdf1f82944897ca6e30d6489f43cf24539374" #--> v4.18.0 ... }
Al fijar los hashes de confirmación, puede evitar desviarse de los registros públicos, que son vulnerables a los ataques a la cadena de suministro.
HCP Terraform:
module "eks_karpenter" { source = "app.terraform.io/my-org/eks/aws" version = "1.1.0" ... enable_karpenter = true }
Terraform Enterprise:
module "eks_karpenter" { source = "terraform.mydomain.com/my-org/eks/aws" version = "1.1.0" ... enable_karpenter = true }
Proveedores de VCS
Los proveedores de VCS apoyan el ref
argumento a favor de seleccionar una revisión específica, como se muestra en los siguientes ejemplos.
GitHub (HTTPS):
module "eks_karpenter" { source = "github.com/my-org/terraform-aws-eks.git?ref=v1.1.0" ... enable_karpenter = true }
Repositorio Git genérico (HTTPS):
module "eks_karpenter" { source = "git::https://example.com/terraform-aws-eks.git?ref=v1.1.0" ... enable_karpenter = true }
Repositorio Git genérico (SSH):
aviso
Debes configurar las credenciales para acceder a los repositorios privados.
module "eks_karpenter" { source = "git::ssh://username@example.com/terraform-aws-eks.git?ref=v1.1.0" ... enable_karpenter = true }
Siga los estándares de codificación
Aplique reglas y estilos de formato de Terraform consistentes en todos los archivos de configuración. Haga cumplir los estándares mediante comprobaciones de estilo automatizadas en las canalizaciones de CI/CD. Cuando incorporas las mejores prácticas de codificación en los flujos de trabajo de los equipos, las configuraciones siguen siendo legibles, fáciles de mantener y colaborativas, ya que su uso se extiende ampliamente en la organización.
Sigue las pautas de estilo
-
Formatee todos los archivos de Terraform (
.tf
archivos) con el comando terraform fmtpara que coincidan HashiCorp con los estándares de estilo. -
Utilice el comando terraform validate
para verificar la sintaxis y la estructura de su configuración. -
Analice estáticamente la calidad del código mediante TFlint.
Este linter comprueba las mejores prácticas de Terraform más allá del simple formateo y falla en las compilaciones cuando encuentra errores.
Configura enlaces previos a la confirmación
Configura enlaces de preconfirmación del lado del cliente que se ejecuten terraform fmt
tflint
checkov
, y otros escaneos de código y comprobaciones de estilo antes de permitir las confirmaciones. Esta práctica te ayuda a validar el cumplimiento de los estándares de forma más temprana en los flujos de trabajo de los desarrolladores.
Utilice marcos de preconfirmación, como la confirmación previa
Al trasladar los controles de estilo y calidad a los enlaces locales previos a la confirmación, los desarrolladores reciben información rápida antes de introducir los cambios. Los estándares pasan a formar parte del flujo de trabajo de codificación.