Curso de Creación y Publicación de Packages en PHP

En este vídeo hacemos un resumen de los contenidos y objetivos que vamos a abordar durante el curso, en las distintas disciplinas que abarcamos, desde el desarrollo con PHP, las pruebas, el diseño del software y las operaciones DevOps.

Cómo inicializar la creación de un proyecto que pretendemos publicar en Packagist, con el comando composer init. Explicamos cómo realizar la configuración inicial del proyecto.

Creamos la clase en cuestión que será la principal en nuestro proyecto, con su espacio de nombres (namespace) y las convenciones necesarias para que funcione en el marco de un package de Composer.

Veremos cómo inicializar el repositorio Git para el control de versiones, que será necesario para publicar el package y configurar los flujos de trabajo. Además daremos unas notas sobre el trabajo con "helpers" que podrías tener en tu package con funciones globales, que no necesitamos, pero que te contamos por si acaso tú las quieres crear en un package.

Todo package profesional debería tener sus propios tests. En este vídeo te explicamos cómo hacerlos y cómo configurar los namespaces específicos para desarrollo y para los test.

Añadimos nuevos test al proyecto para completar nuestros casos de prueba, a fin de tener un package suficientemente robusto.

La idea de este package es crear claves que puedan personalizarse mediante código. En este vídeo veremos cómo crear un API fluída para que el uso de la clase sea muy sencillo e intuitivo, con el que podemos definir las características de la clave que se debe generar.

Cómo iniciar un nuevo proyecto que pretendemos publicar en un package en Packagist. Entender el sistema de autoload, los namespaces que debemos configurar, la estructura del proyecto que se espera, etc.

Antes de comenzar el proceso para publicar el package vamos a conocer algunos detalles de Packagist, que es el sitio que sirve de repositorio de paquetes open source desarrollados en PHP. Veremos algunas cosas interesantes sobre la documentación que nos entregan para explicar el proceso.

En este vídeo vamos a subir el package a Packagist para que esté disponible ya para la comunidad de desarrolladores PHP. Veremos que es un proceso muy sencillo y veremos que, si hemos creado nuestra cuenta de Packagist con nuestro usuario de GitHub se define automáticamente el webhook necesario para que Packagist actualice el paquete cada vez que se cambia la release.

En este vídeo veremos el proceso para actualizar el package, que consiste en crear una nueva tag en el repositorio Git y luego crear una release en GitHub con el mismo nombre. Una vez configurada, si hemos hecho bien el hook, la actualización es automática.

Comenzamos el proyecto de librería de validación para PHP, con la inicialización del proyecto y los namespace para el código de las clases y para el código de test.

En este segundo proyecto de package vamos a aplicar un flujo de trabajo dirigido por pruebas, lo que sería el TDD. Veremos cómo vamos desarrollando el software siguiendo esta metodología.

Vamos avanzando en el proyecto añadiendo reglas de validación, que básicamente es cómo va a escalar nuestro package. Veremos cómo aplicar la nueva regla y explicaremos cómo este código puede transformarse en un problema más adelante cuando tengamos decenas de reglas.

Cómo vamos a gestionar las reglas de validación desconocidas. Explicamos cómo se pueden levantar excepciones para asegurarnos que nadie nos llama mal y cómo podemos testear que estas excepciones ocurren.

Cómo aplicar mejoras en nuestra biblioteca de validación para que también se pueda informar a quienes usan el package sobre los problemas encontrados al validar los datos.

Vamos a aplicar una mejora en la biblioteca de validación para conseguir mejorar el diseño, aplicando una mejor modularidad del software. Comenzamos convirtiendo cada método de validación de una regla particular en una clase.

En esta refactorización vamos a aplicar unas mejoras de un par de patrones conocidos. Vamos a crear una factoría para construir los objetos de validación y aplicar a la vez el patrón strategy, que conseguimos por haber puesto cada regla en su propia clase.

Aplicamos la herramienta de los "data provider" que nos ofrece PHPUnit para mejorar la sencillez de los test y evitar escribir una y otra vez test que son prácticamente copiados de otros, lo que también impactará positivamente en la escalabilidad de las pruebas.

Creamos una regla simple para mostrar lo sencillo que es ahora crear los métodos de test gracias a los data providers.

En esta ocasión vamos a crear reglas un poquito más complejas para poder resolver temas que más tarde o más temprano debería gestionar nuestra biblioteca de validación. Para ello veremos cómo crear reglas parametrizadas.

Vamos a parar un momento la extensión para refactorizar el sistema de parseado de reglas de validación, creando una nueva clase que se especializará en esta tarea. Esta tarea es una refactorización para mejora del diseño, ya que no vamos a cambiar el API ni la funcionalidad.

En este vídeo completamos la funcionalidad de nuestra biblioteca de validación, creando un método que nos permite validar un array asociativo de datos de campos, como el típico que nos llegaría por formulario con $_POST o por querystring con $_GET. Con esto terminaremos, al menos por el momento, de ampliar la funcionalidad de la librería y podremos pasar a definir nuestro sistema de integración continua.

Explicamos los objetivos de esta etapa del curso: implementar un sistema de CI mediante GitHub Actions. Comenzamos por publicar este nuevo paquete en packagist, algo que haremos rápidamente porque ya conocimos el proceso en el vídeo anterior.

Creamos la primera versión del pipeline de integración continua, lo que se llama workflow en el contexto de GitHub Actions. Realizaremos una implementación sencilla para mantener las cosas simples y veremos cómo se ejecuta en GitHub, resolviendo posibles problemas típicos que nos podemos encontrar en el proceso.

De una manera simple podemos construir una matriz de versiones de PHP, que luego podemos usar para que nuestros jobs se ejecuten en cada una de ellas, de modo que podamos asegurar la compatibilidad del package en distintas versiones del lenguaje.

Con GitHub Actions podemos usar una caché de Composer, lo que nos permite que en distintas ejecuciones de los pipelines no se tengan que descargar una y otra vez las mismas dependencias, lo que ahorra tiempo en la instalación y mejora el rendimiento del workflow.

Realizamos una action para publicar la release de manera automática cuando cambia el tag de Git, de este modo podemos automatizar la publicación de versiones en Packagist, aunque siempre de manera controlada, porque la tag la tendremos que realizar de manera manual cuando consideremos oportuno liberar una nueva versión.

Explicamos de manera resumida qué es un pull request y por qué son esenciales para los fluor de trabajo. Hasta ahora habíamos realizado siempre los procesos de CI cuando se hacía push a la rama main pero en este vídeo vamos a comprobar que también se ejecutan las action cuando se hace un pull request.

Realizamos algunas configuraciones extraordinarias del workflow de publicación automática de releases.

Presentamos este paquete para verificación y corrección del estilo de codificación de los proyectos PHP. Instalamos la dependencia y la configuramos adecuadamente, resolviendo problemas derivados de la versión de PHP que podamos estar ejecutando.

En este vídeo veremos cómo cambiar la versión de PHP que estamos usando en nuestro ordenador. Ese es un problema particular que hemos encontrado por nuestra propia configuración de PHP pero que no todos pueden tener.

En este vídeo mostramos que, una vez cambiada la versión de PHP que ejecutamos en loca, CS Fixer ya es capaz de ejecutarse de manera correcta, sin mostrar mensajes de warning.

Entre las cosas que podemos hacer para corregir el estilo del código PHP hay reglas normales y otras reglas calificadas como "risky". En este vídeo veremos qué tipos de reglas pueden ser arriesgadas y qué consideraciones especiales debemos tener en cuenta cuando las aplicamos.

Veremos cómo podemos añadir la comprobación del estilo de codificación PHP a nuestro workflow de CI, mediante la ejecución del comando de PHP CS Fixer en el proyecto

Realizamos las últimas operaciones y análisis automatizado con composer para la publicación de una nueva versión de nuestra librería de validación.

Cómo usar nuestro package de biblioteca de validación en un proyecto, instalando vía composer y realizando la validación de datos que vienen desde un formulario en una página PHP.

Explicamos en qué consiste la práctica final del curso, que tendrás que realizar para obtener el certificado de realización del curso de desarrollo de packages para PHP y Composer.

Aplicación de numerosos refactors que tienen que ver con los principios relacionados con la legibilidad del código.

Refactorizaciones para seguir los principios de ocultación y abstracción.

Aplicación de varias refactorizaciones que se realizan para adoptar distintos principios de modularidad.

Para simplificar, minimizando y unificando, se hace una refactorización en la que el concepto de rule se aplica como un validador, habiendo en el proyecto validadores simples y compuestos.

Los cambios anteriores nos llevan a producir cambios en la interfaz de los validadores simples.

Se ha decidido que es más claro que al construir un objeto validador se le manden las reglas que tiene que aplicar cuando le piden validar. De este modo también se consigue que la interfaz de un validador compuesto se adapte a un validador simple.

Con todos estos cambios se ha modificado el API de nuestra biblioteca de validación, por lo que actualizamos el readme y publicamos una nueva versión que tiene breaking changes.

En el caso de la regla parametrizada "max:", se ha decidido que el parseo lo debe realizar el propio validador, lo que mejora la cohesión y la abstracción.

En la clase ValidatorsFactory aplicamos diseño por contrato, creando una precondición para que no nos llamen si no nos entregan una lista correcta de nombres de reglas de validación.

Con los cambios del vídeo anterior ha quedado patente nuestro patrón strategy para modularización de los validadores simples y esos cambios hacen adecuado basarse en el catálogo de estrategias cuando queremos ver si una regla de validación hace match con alguno de los validadores existentes.

En este vídeo simplemente adelantamos las mejoras que queremos conseguir en las próximas clases, explicando cómo es el modo de trabajo que queremos conseguir, usando el patrón composite.

Antes de comenzar a cambiar las clases para adaptarnos a la nueva interfaz de trabajo, vamos a realizar los cambios en algunas clases y propiedades que nos solicitó Luis en la pasada corrección.

Vamos a comenzar el desarrollo de las mejoras de nuestro package implementando un método create() dentro de ValidatorsFactory, para que pueda ayudarnos a crear validadores de diversos tipos, atendiendo al formato de las reglas de validación que le entreguemos.

En el vídeo anterior se detectó que existe un ciclo en nuestras clases y queremos eliminarlo para evitar ese problema de diseño.

En este video vamos a aplicar un poco de diseño por contrato para definir unas precondiciones que serán comprobadas antes de ejecutar los métodos de validación. Para ello mejoraremos los test para encontrar los casos que podrían dar problemas, para luego actualizar las clases del package.

Acabamos este proceso de mejoras de diseño implementando unas precondiciones con asserts, para asegurarnos que se crean los validadores de campos enviando los parámetros correctos al constructor. Además veremos cómo hacer tests que verifiquen que los asserts funcionan y, por último, cómo configurar PHPUnit para que los asserts también estén activos en el entorno de ejecución de las pruebas en GitHub Actions, de modo que los tests funcionen bien también en el entorno de pruebas de Continuous Integration.