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.