

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.

# Comprensión de los DevOps entornos
<a name="understanding-the-devops-environments"></a>

Para comprender las estrategias de ramificación, debe comprender el propósito y las actividades que se llevan a cabo en cada entorno. El establecimiento de varios entornos le ayuda a separar las actividades de desarrollo en etapas, a supervisarlas y a evitar el lanzamiento involuntario de funciones no aprobadas. Puede tener uno o más Cuentas de AWS en cada entorno. 

La mayoría de las organizaciones tienen varios entornos descritos para su uso. Sin embargo, la cantidad de entornos puede variar según la organización y según las políticas de desarrollo de software. En esta serie de documentación se supone que tiene los siguientes cinco entornos comunes que abarcan su proceso de desarrollo, aunque es posible que tengan nombres diferentes:
+ **Sandbox**: un entorno en el que los desarrolladores escriben código, cometen errores y realizan trabajos de prueba de concepto.
+ **Desarrollo**: un entorno en el que los desarrolladores integran su código para confirmar que todo funciona como una aplicación única y cohesiva.
+ **Pruebas**: un entorno en el que se llevan a cabo equipos de control de calidad o pruebas de aceptación. Los equipos suelen realizar pruebas de rendimiento o integración en este entorno.
+ **Preparación: un** entorno de preproducción en el que se valida que el código y la infraestructura funcionan según lo esperado en circunstancias equivalentes a las de producción. Este entorno está configurado para ser lo más parecido posible al entorno de producción.
+ **Producción**: un entorno que gestiona el tráfico de los usuarios finales y los clientes.

En esta sección se describe cada entorno en detalle. También describe los pasos de creación, los pasos de implementación y los criterios de salida de cada entorno para que pueda continuar con el siguiente. La siguiente imagen muestra estos entornos en secuencia.

![\[DevOps Entornos comunes en orden secuencial\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/choosing-git-branch-approach/images/devops-environments.png)


**Topics**
+ [Entorno sandbox](sandbox-environment.md)
+ [Entorno de desarrollo](development-environment.md)
+ [Entorno de pruebas](testing-environment.md)
+ [Entorno de puesta en escena](staging-environment.md)
+ [Entorno de producción](production-environment.md)

# Entorno sandbox
<a name="sandbox-environment"></a>

El *entorno sandbox* es el lugar donde los desarrolladores escriben código, cometen errores y realizan trabajos de prueba de concepto. Puede realizar la implementación en un entorno sandbox desde una estación de trabajo local o mediante un script en una estación de trabajo local.

## Acceso
<a name="access"></a>

Los desarrolladores deben tener acceso completo al entorno sandbox.

## Pasos de construcción
<a name="build-steps"></a>

Los desarrolladores ejecutan la compilación manualmente en sus estaciones de trabajo locales cuando están preparados para implementar cambios en el entorno sandbox.

1. Usa [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) para buscar información confidencial

1. Borra el código fuente

1. Compila y compila el código fuente, si corresponde

1. Realice pruebas unitarias

1. Realice un análisis de cobertura de código

1. Realizar un análisis de código estático

1. Cree la infraestructura como código (IaC)

1. Realice un análisis de seguridad de IaC

1. Extraiga licencias de código abierto

1. Publica artefactos de construcción

## Pasos de implementación
<a name="deployment-steps"></a>

Si utilizas los modelos Gitflow o Trunk, los pasos de implementación se inician automáticamente cuando una `feature` rama se crea correctamente en el entorno sandbox. Si utilizas el modelo GitHub Flow, debes realizar manualmente los siguientes pasos de despliegue. Los siguientes son los pasos de implementación en el entorno sandbox:

1. Descargue los artefactos publicados

1. Realice el versionado de la base de datos

1. Realice el despliegue de iAC

1. Realice pruebas de integración

## Expectativas antes de pasar al entorno de desarrollo
<a name="expectations-before-moving-to-the-development-environment"></a>
+ Construcción exitosa de la `feature` sucursal en un entorno sandbox
+ Un desarrollador implementó y probó la función manualmente en el entorno sandbox

# Entorno de desarrollo
<a name="development-environment"></a>

El *entorno de desarrollo* es donde los desarrolladores integran su código para garantizar que todo funcione como una aplicación cohesiva. En Gitflow, el entorno de desarrollo contiene las últimas funciones incluidas en la solicitud de fusión y están listas para su lanzamiento. En las estrategias GitHub Flow y Trunk, el entorno de desarrollo se considera un entorno de pruebas y el código base puede ser inestable e inadecuado para su despliegue en producción.

## Acceso
<a name="access"></a>

Asigne los permisos de acuerdo con el principio de privilegios mínimos. El *privilegio mínimo* es la práctica recomendada de seguridad que consiste en conceder los permisos mínimos necesarios para realizar una tarea. Los desarrolladores deberían tener menos acceso al entorno de desarrollo que al entorno sandbox.

## Pasos de construcción
<a name="build-steps"></a>

Al crear una solicitud de fusión para la `develop` rama (Gitflow) o la `main` rama (Trunk o GitHub Flow), se inicia automáticamente la compilación.

1. Usa [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) para buscar información confidencial

1. Borra el código fuente

1. Compila y compila el código fuente, si corresponde

1. Realice pruebas unitarias

1. Realice un análisis de cobertura de código

1. Realizar un análisis de código estático

1. Construye iAC

1. Realice un análisis de seguridad de IaC

1. Extraiga licencias de código abierto

## Pasos de implementación
<a name="deployment-steps"></a>

Si utilizas el modelo de Gitflow, los pasos de despliegue se inician automáticamente cuando una `develop` rama se ha creado correctamente en el entorno de desarrollo. Si utilizas el modelo GitHub Flow o el modelo Trunk, los pasos de despliegue se inician automáticamente cuando se crea una solicitud de fusión en la `main` sucursal. Los siguientes son los pasos de implementación en el entorno de desarrollo:

1. Descargue los artefactos publicados desde los pasos de construcción

1. Realice el versionado de la base de datos

1. Realice el despliegue de iAC

1. Realice pruebas de integración

## Expectativas antes de pasar al entorno de pruebas
<a name="expectations-before-moving-to-the-testing-environment"></a>
+ Creación e implementación satisfactorios de la `develop` rama (Gitflow) o la `main` sucursal (Trunk o GitHub Flow) en el entorno de desarrollo
+ Las pruebas unitarias se aprueban al 100%
+ Construcción exitosa de iAC
+ Los artefactos de despliegue se crearon correctamente
+ Un desarrollador ha realizado una verificación manual para confirmar que la función funciona según lo esperado

# Entorno de pruebas
<a name="testing-environment"></a>

El personal de control de calidad (QA) utiliza el entorno de pruebas para validar las características. Aprueban los cambios una vez finalizadas las pruebas. Cuando lo aprueban, la sucursal pasa al siguiente entorno, el de puesta en escena. En Gitflow, este entorno y otros anteriores solo están disponibles para su implementación desde `release` sucursales. Una `release` sucursal se basa en una `develop` rama que contiene las funciones planificadas.

## Acceso
<a name="access"></a>

Asigne los permisos de acuerdo con el principio de privilegios mínimos. Los desarrolladores deberían tener menos acceso al entorno de pruebas que al entorno de desarrollo. El personal de control de calidad necesita permisos suficientes para probar la función.

## Pasos de construcción
<a name="build-steps"></a>

El proceso de compilación en este entorno solo se aplica a las correcciones de errores cuando se utiliza la estrategia de Gitflow. Al crear una solicitud de fusión para la `bugfix` sucursal, se inicia automáticamente la compilación.

1. Usa [git-secrets](https://github.com/awslabs/git-secrets) (GitHub) para buscar información confidencial

1. Borra el código fuente

1. Compila y compila el código fuente, si corresponde

1. Realice pruebas unitarias

1. Realice un análisis de cobertura de código

1. Realizar un análisis de código estático

1. Construye iAC

1. Realice un análisis de seguridad de IaC

1. Extraiga licencias de código abierto

## Pasos de implementación
<a name="deployment-steps"></a>

Inicie automáticamente el despliegue de la `release` sucursal (Gitflow) o de la `main` sucursal (Trunk o GitHub Flow) en el entorno de prueba tras el despliegue en el entorno de desarrollo. Los siguientes son los pasos de implementación en el entorno de pruebas:

1. Implemente la `release` rama (Gitflow) o la `main` rama (Trunk o GitHub Flow) en el entorno de prueba

1. Haga una pausa para la aprobación manual por parte del personal designado

1. Descarga los artefactos publicados

1. Realice el versionado de la base de datos

1. Realice el despliegue de iAC

1. Realice pruebas de integración

1. Realice pruebas de rendimiento

1. Aprobación de control de calidad

## Expectativas antes de pasar al entorno de ensayo
<a name="expectations-before-moving-to-the-staging-environment"></a>
+ Los equipos de desarrollo y control de calidad han realizado suficientes pruebas para satisfacer los requisitos de su organización.
+ El equipo de desarrollo ha resuelto los errores descubiertos a través de una `bugfix` sucursal.

# Entorno de puesta en escena
<a name="staging-environment"></a>

El *entorno de ensayo* está configurado para ser el mismo que el entorno de producción. Por ejemplo, la configuración de los datos debe ser similar en alcance y tamaño a las cargas de trabajo de producción. Utilice el entorno de ensayo para comprobar que el código y la infraestructura funcionan según lo esperado. Este entorno también es la opción preferida para los casos de uso empresarial, como las vistas previas o las demostraciones para clientes.

## Acceso
<a name="access"></a>

Asigne los permisos de acuerdo con el principio de privilegios mínimos. Los desarrolladores deben tener el mismo acceso al entorno de ensayo que al entorno de producción.

## Pasos de construcción
<a name="build-steps"></a>

Ninguna. Los mismos artefactos que se usaron en el entorno de prueba se reutilizan en el entorno de ensayo.

## Pasos de implementación
<a name="deployment-steps"></a>

Inicie automáticamente el despliegue de la `release` rama (Gitflow) o la `main` sucursal (Trunk o GitHub Flow) en el entorno de ensayo tras la aprobación y el despliegue en el entorno de prueba. Los siguientes son los pasos de implementación en el entorno provisional:

1. Implemente la `release` rama (Gitflow) o la `main` rama (Trunk o GitHub Flow) en el entorno de ensayo

1. Haga una pausa para la aprobación manual por parte del personal designado

1. Descarga los artefactos publicados

1. Realice el versionado de la base de datos

1. Realice el despliegue de iAC

1. (Opcional) Realice pruebas de integración

1. (Opcional) Realice pruebas de carga

1. Obtenga la aprobación de los responsables de desarrollo, control de calidad, productos o empresas necesarios

## Expectativas antes de pasar al entorno de producción
<a name="expectations-before-moving-to-the-production-environment"></a>
+ Se implementó correctamente una versión equivalente a la producción en el entorno de ensayo
+ (Opcional) Las pruebas de integración y carga se realizaron correctamente

# Entorno de producción
<a name="production-environment"></a>

El *entorno de producción* respalda el producto lanzado y gestiona datos reales de clientes reales. Se trata de un entorno protegido al que se le asigna el acceso con el mínimo privilegio y el acceso elevado solo debe permitirse mediante un proceso de excepción auditado durante un período de tiempo limitado.

## Acceso
<a name="access"></a>

En el entorno de producción, los desarrolladores deben tener acceso limitado y de solo lectura a la consola de administración de AWS. Por ejemplo, los desarrolladores deberían poder acceder a los datos de registro para day-to-day las operaciones. Todas las versiones para producción deben estar sujetas a un paso de aprobación antes de su implementación.

## Pasos de construcción
<a name="build-steps"></a>

Ninguna. Los mismos artefactos que se usaron en los entornos de prueba y puesta en escena se reutilizan en el entorno de producción.

## Pasos de implementación
<a name="deployment-steps"></a>

Inicie automáticamente el despliegue de la `release` sucursal (Gitflow) o la `main` sucursal (Trunk o GitHub Flow) en el entorno de producción tras la aprobación y el despliegue en el entorno provisional. Los siguientes son los pasos de implementación en el entorno de producción:

1. Implemente la `release` sucursal (Gitflow) o la `main` rama (Trunk o GitHub Flow) en el entorno de producción

1. Haga una pausa para la aprobación manual por parte del personal designado

1. Descarga los artefactos publicados

1. Realice el versionado de la base de datos

1. Realice el despliegue de iAC