---
# System prepended metadata

title: 'P12: Proceso para crear un Pull Request'

---

# P12: Proceso para crear un Pull Request

## Objetivos

  1. Crear una solicitud de incorporación de código entendible por humanos y máquinas. 

## Involucrados
  1. Todo el equipo de desarrollo

## Entradas

  1. Cambios en el código
  2. Necesidad de revisión de código. 

## Etapas y descripciones

<table>
  <thead>
    <tr>
      <th>Etapa</th>
      <th>Actividad</th>
      <th>Encargado</th>
      <th>Practica del CMMI</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td rowspan=6>Creación del PR</td>
      <td>
        Asigna un nombre al PR, siguiendo el siguiente formato
        `<feat|fix|cualquier prefijo aceptado por <a href="https://www.conventionalcommits.org/en/v1.0.0/">CC<a>>/<jira ticket ID>/<nombre del cambio>`. Este formato permite tener un versionamiento semántico. 
      </td>
      <td rowspan=8>Desarrollador asignado del cambio</td>
      <td>VER1.1, CM</td>
    </tr>
    <tr>
      <td>Llenar todos los campos (o los que apliquen) de la descripción del PR, para así dar más información a los reviewers del cambio.</td>
      <td>VER1.1, CM</td>
    </tr>
    <tr>
      <td>Asignar al encargado del PR (o a si mismo si es que aplica).</td>
      <td>VER2.1, CM</td>
    </tr>
    <tr>
      <td>Seleccionar encargados de la revisión (reviewers), o dejar que Github asigne automáticamente.</td>
      <td>VER2.1, CM</td>
    </tr>
    <tr>
      <td>Seleccionar el tab "state:ready-for-review".</td>
      <td>VER2.1, CM</td>
    </tr>
    <tr>
      <td>En la descripción del PR, añada preguntas para sus reviewers. También, si aplica, personalice los elementos del checklist al final de la descripción.</td>
      <td>VER1.3, CM</td>
    </tr>
    <tr>
      <td rowspan=2>Creación de entorno de prueba</td>
      <td>Decidir si se necesita un entorno de prueba en la nube o solamente descargar la rama con los cambios y probar localmente. Si se necesita un entorno en la nube, en el pipeline actual de Heroku crear dos nuebas aplicaciones: una para baclend y otra para frontend. Apoyarse de su dueño de arquitectura para tener la configuración adecuada o siga el <a href="#">proceso para crear un entorno de verificación</a> (pendiente).</td>
      <td>VER1.2</td>
    </tr>
    <tr>
      <td>Notificar en el medio de comunicación adecuado que se ha creado un nuevo PR y que está listo para revisión. Así mismo, notificar si es necesario o no el entorno de pruebas en la nube.</td>
      <td>VER2.1</td>
    </tr>

  </tbody>
</table>

## Salidas

  1. \<Salida 1\>
  2. \<Salida 2\>
  ...

## Referencias
[Conventional Commits V1.0.0 (CC)][1]

[1]: https://www.conventionalcommits.org/en/v1.0.0/
