Modelo de control de versiones

Esquema de identificación de objetos

Tipos de archivo

Archivo	Extensión
HTML	.html
JavaScript	.js
TypeScript	.ts
PDF	.pdf
JSON	.json
Markdown	.md
CSS	.css

Estándar nombres de archivo

1. Seguir un patrón que describa la característica del componente y luego su tipo. El patrón recomendado es feature.type.ts.

2. Utilizar guiones para separar palabras en el nombre descriptivo. 

3. Utilizar puntos para separar el nombre descriptivo del tipo.

4. Utilizar nombres coherentes para todos los assets con el nombre de lo que representan.

5. Utilizar la notación de camello para el nombre de las clases.

6. Coincidir el nombre del componente con el del archivo.

7. Agregue el nombre del símbolo con el sufijo convencional (como Componente, Directiva, Módulo, Tubería o Servicio)

8. Dar al archivo el sufijo convencional (como .component.ts, .directive.ts, .module.ts, .pipe.ts o .service.ts) para un archivo de ese tipo.

9. Usar nombres consistentes a todos los servicios con su función.

10. Agregue el sufijo de un nombre de clase de servicio con Service. Por ejemplo, algo que obtiene datos o héroes debe llamarse DataService o HeroService.

Estructura de directorios

Archivos de configuración del entorno de trabajo

Archivo	Propósito
.editorconfig	Configuración para los editores de código.
.gitignore	Específica los archivos que Git tiene que ignorar.
README.md	Documentación introductoria de la aplicación.
angular.json	Configuración por defecto del CLI de todos los proyectos en el espacio de trabajo, incluyendo las opciones de configuración para compilar, servir y probar.
package.json	Configura las dependencias de npm que están disponibles en todos los proyectos en el espacio de trabajo.
package-lock.json	Proporciona información acerca de las versiones de todos los paquetes instalados en node_modules por el cliente npm.
src/	Archivos de código fuente de la aplicación principal.
node_modules/	Proporciona los paquetes npm de todo el entorno de trabajo.
tsconfig.json	Archivo de configuración de estilo de TypeScript para los editores de texto.
tsconfig.base.json	La configuración base de TypeScript para todos los proyectos en el entorno de trabajo.
tslint.json	Configuración por defecto de TSLint para todos los proyectos en el entorno de trabajo.

Archivos de origen de la aplicación

Archivo	Propósito
app/	Contiene los archivos de componente en los cuales la lógica y datos de la aplicación están definidas.
assets/	Contiene imágenes y otros archivos usados en la aplicación.
environments/	Contiene opciones de configuración para la compilación para determinados entornos.
favicon.ico	Icono usado para la aplicación en la barra de marcadores.
index.html	La página HTML principal de la aplicación, esta es mostrada cuando alguien visita la aplicación.
main.ts	El punto de entrada principal de la aplicación.
polyfills.ts	Proporciona los scripts polyfill para soporte del navegador.
styles.sass	Lista de archivos CSS que dan estilo al proyecto.
test.ts	Punto de entrada principal para pruebas unitarias, con algunas configuraciones específicas de Angular.
app/app.component.ts	Define la lógica del componente principal de la aplicación.
app/app.component.html	Define la vista HTML asociado al componente principal.
app/app.component.css	Define el archivo CSS base del componente principal.
app/app.component.spec.ts	Define una prueba unitaria para el componente principal.
app/app.module.ts	Define el módulo principal, este es llamado cuando se compila la aplicación.
app/package.json	Archivo usado para informar a las herramientas la locación del proyecto principal

Archivos de configuración de la aplicación

Archivo	Propósito
.browserslistrc	Configura la compartición entre navegadores objetivo y la versión de Node.js en varias herramientas frontend.
karma.conf.js	Archivo de configuración de Karma.
tsconfig.app.json	Archivo de configuración de TypeScript.
tsconfig.spec.json	Archivo de configuración para pruebas.
tslint.json	Archivo de configuración de TSLint.

Archivos de prueba end-to-end

Archivo	Propósito
e2e/src/	Pruebas end-to-end para la aplicación.
e2e/protractor.conf.js	Archivo de configuración de herramienta.
tsconfig.json	Archivo de configuración de TypeScript.

Esquema de nomenclatura de versiones

Se van a asignar dos números, mayor.menor.micro que irán incrementando conforme el desarrollo de la aplicación aumente y requiera las asignación de un nuevo nombre. Se aumentarán los números mayor, menor y micro bajo los siguientes criterios:

• Mayor. La aplicación sufre grandes cambios o mejoras.

• Menor. La aplicación sufre pequeños cambios o mejoras.

• Micro. Se corrige un error pequeño o se aplica un cambio pequeño.

Para poder hacer una publicación se utilizarán los siguientes comandos:

Flujo de trabajo a utilizar

Gitflow

El flujo de trabajo de Gitflow define un modelo de creación de ramas estricto diseñado con la publicación del proyecto como fundamento. Este flujo de trabajo no añade ningún concepto o comando nuevo, solo los que se necesitan para el flujo de trabajo de rama de función. En su lugar, asigna funciones muy específicas a las distintas ramas y define cómo y cuándo deben realizarse las interacciones. 

Justificación

Porque Gitflow es ideal para los proyectos que tienen un ciclo de publicación programado, además que este maneja una rama por cada funcionalidad evitando que surjan conflictos de fusión, proporcionando una implementación más limpia. En contraste a otros flujos centralizados, este da la posibilidad de poder trabajar en distintas ramas sin afectar el flujo de trabajo del equipo, permitiendo un ciclo de desarrollo sin obstáculos y aumenta considerablemente la productividad.

Funcionamiento

Ramas de desarrollo y maestras

En vez de una única rama maestra, este flujo de trabajo utiliza dos ramas para registrar el historial del proyecto. La rama maestra almacena el historial de publicación oficial y la rama de desarrollo sirve como rama de integración para funciones. Asimismo, conviene etiquetar todas las confirmaciones de la rama maestra con un número de versión. Al utilizar la biblioteca de extensiones de git-flow, ejecutar git flow init en un repositorio existente creará la rama de desarrollo:

Ramas de función

Cada nueva función debe estar en su propia rama, que se puede enviar al repositorio central para copia de seguridad/colaboración. Sin embargo, en vez de ramificarse de la maestra, las ramas de función utilizan la de desarrollo como rama primaria. Cuando una función está completa, se vuelve a fusionar en la de desarrollo. Las funciones nunca deben interactuar directamente con la maestra.

 

Las ramas de función normalmente se crean a partir de la última rama de desarrollo.

Creación de una rama de función

Finalización de una rama de función

Ramas de publicación

Una vez que el desarrollo ha adquirido suficientes funciones para una publicación (o se está acercando una fecha de publicación predeterminada), se bifurca una rama de versión a partir de una de desarrollo. Al crear esta rama, se inicia el siguiente ciclo de publicación, por lo que no pueden añadirse nuevas funciones tras este punto; solo las soluciones de errores, la generación de documentación y otras tareas orientadas a la publicación deben ir en esta rama. Una vez que esté lista para el lanzamiento, la rama de publicación se fusiona en la maestra y se etiqueta con un número de versión. Además, debería volver a fusionarse en la de desarrollo, que podría haber progresado desde que se inició la publicación. Utilizar una rama específica para preparar publicaciones hace posible que un equipo perfeccione la publicación actual mientras otro equipo sigue trabajando en las funciones para la siguiente publicación. Crear ramas de publicación es otra operación de ramificación sencilla. Al igual que las ramas de función, las ramas de publicación se basan en la rama de desarrollo. Se puede crear una nueva rama de publicación utilizando el siguiente comando:

Una vez que la publicación esté lista para su lanzamiento, se fusionará en la maestra y la de desarrollo; a continuación, se eliminará la rama de publicación. Es importante volver a fusionarla en la de desarrollo porque podrían haberse añadido actualizaciones críticas a la rama de publicación y las nuevas funciones tienen que poder acceder a ellas.

Ramas de corrección

Las ramas de mantenimiento o "corrección" (hotfix) se utilizan para reparar rápidamente las publicaciones de producción. Las ramas de corrección son muy similares a las ramas de publicación y a las de función, salvo porque se basan en la maestra en vez de la de desarrollo. Es la única rama que debería bifurcarse directamente a partir de la maestra. Una vez que la solución esté completa, debería fusionarse en la maestra y la de desarrollo (o la rama de publicación actual), y la maestra debería etiquetarse con un número de versión actualizado. 

Tener una línea de desarrollo específica para la solución de errores permite que tu equipo aborde las incidencias sin interrumpir el resto del flujo de trabajo ni esperar al siguiente ciclo de publicación. Puedes considerar las ramas de mantenimiento como ramas de publicación ad hoc que trabajan directamente con la maestra. Una rama de corrección puede crearse utilizando el siguiente comando:

Al igual que al finalizar una rama de publicación, una rama de corrección se fusiona tanto en la maestra como en la de desarrollo.

Fuente: https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow