Este procedimiento es una propuesta para proyectos grandes en los que hay muchas personas implicadas, y en los que se requiere cierto control de las actualizaciones.
En la propuesta intervienen distintos equipos, aunque se van a resumir en 2 o 3, como son tecnología, seguridad y el equipo editorial. En cualquier caso, podemos separarlo en dos, el equipo técnico y el editorial.
Como digo, es una propuesta, basada en un proyecto específico, por lo que debería adaptarse a cada caso concreto.
Tabla de contenidos
- Entornos
- Actualización de infraestructura
- Actualización del núcleo de WordPress
- Actualización de complementos de WordPress
- Accesos
Entornos
Vamos a disponer de 3 entornos a la hora de trabajar con WordPress.
Entorno de desarrollo (devel)
El entorno de desarrollo será un entorno obsoleto en cuanto a contenidos (por defecto) pero alineado en cuanto a configuraciones.
Este entorno tendrá, siempre que sea posible, las últimas versiones aplicadas de cualquier parte de WordPress, ya sea infraestructura, WordPress o complementos.
Aquí podremos encontrar versiones superiores a las que se vayan a aplicar en producción, por lo que, aunque sea una versión pública, no se ha de tomar de referencia para los pases a producción.
Entorno de preproducción (staging)
Este entorno se plantea como una versión previa al pase a producción. Se generará con una copia lo más actual posible del sitio de producción, para poder comparar contenidos.
En esta versión se aplicarán los cambios que se documenten en el Changelog de versiones de pase a producción.
En una línea de tiempo tendríamos:
A –3 días, con la recogida de todos los cambios y la presentación del Changelog.
A –2 días creación del entorno de staging y una URL pública para analizar los cambios.
Entorno de producción (pro)
El entorno de producción es el entorno al que los usuarios finales acceden. El sistema tiene copias automáticas en varios lugares y formatos.
Previo a las actualizaciones se realizará una copia de seguridad en local y remoto para una recuperación rápida.
Las actualizaciones se aplicarán según lo diseñado en el Changelog y, por tanto, aprobado según el entorno de preproducción.
Actualización de infraestructura
Vamos a definir la infraestructura como la parte que puede hacer referencia a todo lo que afecta a los WordPress, pero no es WordPress.
Esto afectaría principalmente a las máquinas y configuraciones de las máquinas virtuales, o entornos en la nube, donde encontramos las configuraciones de MariaDB, nginx, PHP, Redis y otros elementos que conforman los WordPress.
Las actualizaciones de la infraestructura se plantean de la siguiente manera.
Actualizaciones de seguridad del Sistema Operativo
El sistema operativo Linux (en este caso Ubuntu) está configurado para que las actualizaciones críticas de seguridad se apliquen de manera automática.
Actualizaciones de seguridad de servicios
En caso de que haya alguna actualización de seguridad que pueda afectar a alguno de los componentes de WordPress, como puede ser nginx, PHP o Redis, se dará un aviso y en el plazo de 24 horas se plantea el procedimiento de actualización. Será un procedimiento de silencio administrativo, por lo que, si nadie dice nada en contra, se aplicarán los parches.
Actualizaciones normales
El primer lunes de cada mes se planificará la actualización de la infraestructura de forma normal.
Actualización del núcleo de WordPress
Este apartado hace referencia en exclusiva a las actualizaciones del propio WordPress, es decir, su núcleo.
WordPress funciona por un sistema de versiones mayores y menores (o parches). Las versiones mayores son aquellas que vienen identificadas por las dos primeras cifras (por ejemplo, 5.8, 5.9 o 6.0). Las versiones menores (o parches) vienen definidas por una tercera cifra (5.9.1, 5.9.2, 5.9.3).
Las versiones mayores, entre sus cambios, pueden incluir funcionalidades nuevas, añadir o eliminar ficheros o hacer cambios en la estructura de la base de datos.
Las versiones menores se limitan a hacer cambios y mejoras en las funcionalidades existentes, además de la aplicación de parches de seguridad.
Actualizaciones menores
Por defecto WordPress aplica actualizaciones automáticas en las versiones menores, ya que conllevan un riesgo mínimo, y suelen implicar correcciones de errores o parches de seguridad.
La configuración por defecto será la aplicación de estos parches de forma automática por el propio WordPress de forma automática.
Actualizaciones mayores
Las actualizaciones mayores de WordPress suelen tener un calendario previsto unos 3 meses antes de su lanzamiento. Además, por norma general, se incluyen al menos una versión beta, y una versión candidata, previas al lanzamiento.
Las actualizaciones mayores se aplicarán en una versión candidata en el entorno de desarrollo en el momento en el que estén disponibles y, por tanto, se podrán observar las posibles incompatibilidades o mejoras que haya pendientes.
El objetivo es que, el día en el que aparezca la versión mayor de forma oficial, se pueda aplicar la actualización de forma planificada y ya con una revisión de compatibilidad de los complementos.
Actualización de complementos de WordPress
WordPress tiene dos tipos de complementos: plugins y temas.
La forma de gestionar ambos es similar, ya que se pueden actualizar desde el repositorio oficial de WordPress y, por tanto, con un clic desde el panel. También se pueden actualizar desde sitios externos que permiten actualización desde el panel, normalmente bajo licencia, o se pueden actualizar de manera manual subiendo un ZIP con el complemento desde la zona de Subir plugin, o Subir tema, del propio panel de administración.
Aunque los complementos suelen seguir la misma forma semántica de versiones que WordPress, cada desarrollador aplica sus propios métodos.
Temas
Los temas hacen referencia a los elementos que se muestran a los usuarios, el frontend del sitio. Una característica de los temas es que no han de incluir funcionalidades que puedan servir en otros temas. Para estos casos, se debe incluir un plugin complementario a determinadas funcionalidades, ya que, si se cambia de tema, estas deben seguir funcionando.
Actualizaciones menores
Se considera una actualización menor de un tema aquella que hace referencia a la mejora, corrección o cambio de algún elemento del frontal, pero sin incluir funcionalidades nuevas. Esto hace de por sí que solo haya pequeños cambios en el código, correcciones, pero que no se añadan o modifiquen los ficheros de forma grande o que genere incompatibilidades. Por ejemplo, una versión menor no debería adaptarse a una nueva versión de PHP.
Las actualizaciones menores se realizarán de forma semanal, cada lunes.
El procedimiento será el de presentar el Changelog el A –1 día. Se aplicarán los cambios en el último entorno de preproducción disponible. El día A se aplicarán los cambios.
Actualizaciones mayores
Se considera una actualización mayor de un tema aquella que hace referencia a la ampliación de funcionalidades o cambio de compatibilidades del tema con WordPress o la infraestructura. Este cambio puede incluir el añadir o eliminar ficheros, o una reescritura de funciones o elementos completos, por ejemplo, para adaptarse a una nueva versión de WordPress.
Las actualizaciones mayores se incluirán en el ciclo de actualización principal, actualmente el tercer lunes de cada mes, y se incluirán los cambios en el Changelog principal.
Actualizaciones de emergencia y seguridad
En el caso en el que se detecte algún problema de seguridad en alguno de los temas, principalmente los desarrollados a medida, se podrá generar una versión menor específica que arregle esa parte del código, sin que se incluya ningún cambio que pueda entrar dentro de las actualizaciones menores.
En ese caso, se generará el fichero, se presentarán los cambios, y en el plazo de 24 horas se aplicará como una actualización de seguridad.
Plugins
Los plugins hacen referencia a los complementos que se pueden incluir en WordPress, que pueden afectar tanto al frontal como al panel de administración u otros componentes y que añaden una funcionalidad específica al sistema.
Plugins hay de muchos tipos, aunque en mayor medida podemos separarlos en dos. Aquellos que hacen referencia a funcionalidades intrínsecas de la plataforma, como pueden ser plugins de seguridad, de caché, o herramientas que interactúan con la infraestructura, y aquellos otros que añaden funcionalidades para mejorar el sitio, su edición o funcionalidades no nativas del sistema.
Actualizaciones menores
Se considera una actualización menor de un plugin aquella que hace referencia a la mejora, corrección o cambio de algún elemento, pero sin incluir funcionalidades nuevas. Esto hace de por sí que solo haya pequeños cambios en el código, revisiones, pero que no se añadan o modifiquen los ficheros de forma grande o que genere incompatibilidades. Por ejemplo, una versión menor no debería adaptarse a una nueva versión de PHP.
Las actualizaciones menores se realizarán de forma semanal.
El procedimiento será el de presentar el Changelog el A –1 día. Se aplicarán los cambios en el último entorno de preproducción disponible. El día A se aplicarán los cambios.
Actualizaciones mayores
Se considera una actualización mayor de un plugin aquella que hace referencia a la ampliación de funcionalidades o cambio de compatibilidades con WordPress o la infraestructura. Este cambio puede incluir el añadir o eliminar ficheros, o una reescritura de funciones o elementos completos, por ejemplo, para adaptarse a una nueva versión de WordPress.
Las actualizaciones mayores se incluirán en el ciclo de actualización principal, actualmente el tercer lunes de cada mes, y se incluirán los cambios en el Changelog principal.
Actualizaciones de emergencia y seguridad
En el caso en el que se detecte algún problema de seguridad en alguno de los plugins, principalmente los desarrollados a medida, se podrá generar una versión menor específica que arregle esa parte del código, sin que se incluya ningún cambio que pueda entrar dentro de las actualizaciones menores.
En ese caso, se generará el fichero, se presentarán los cambios, y en el plazo de 24 horas se aplicará como una actualización de seguridad.
Accesos
Se considera acceso al sistema que permita a un usuario conectarse a cualquiera de los sistemas de uso del WordPress, ya sea la infraestructura (SSH, SFTP, Git) o al propio WordPress (usuario y contraseña del panel de administración).
Acceso a la Infraestructura
Habrá dos niveles de acceso a la infraestructura.
El acceso a las máquinas de desarrollo será de acceso abierto a todos los equipos de sistemas y desarrollo, incluso de acceso root a la máquina si fuera necesario.
La infraestructura de desarrollo está configurada para ser una máquina 100% independiente del resto de los sistemas.
El acceso a las máquinas de preproducción y producción estarán limitadas exclusivamente a los equipos de sistemas y seguridad.
Acceso al WordPress
WordPress dispone de un sistema de niveles de acceso propio, del que podemos destacar 3 niveles.
Niveles de acceso
Colaborador
Aquellos usuarios que tengan que gestionar sus contenidos en WordPress pero no tengan porqué editar contenidos de terceros. Un ejemplo podría ser un colaborador externo.
Editor
Los editores son aquellos usuarios que tienen acceso a la gestión completa de los contenidos (añadir, modificar y eliminar). Entre los contenidos podemos incluir entradas, páginas y multimedia (fotografías, vídeos, audios).
Administrador
El administrador es aquel usuario que puede gestionar y mantener el WordPress, pero no está planteado que sea parte del equipo editorial (es decir, su usuario no debería tener ningún contenido publicado).
Gestión de los usuarios en preproducción y producción
En los entornos de preproducción y producción los usuarios de administrador que tendrán acceso son aquellos que gestionen la plataforma a nivel de sistemas, es decir, los equipos de sistemas y seguridad.
Aquellas personas que simplemente se dediquen a la creación de contenidos tendrán acceso de Colaborador.
Aquellas personas que realicen la revisión, publicación y programación de los contenidos, incluidos los equipos de SEO, tendrán un nivel de Editor.
Todos los usuarios con acceso Administrador y Editor tendrán que disponer de un sistema de 2FA activado, ya sea mediante la validación de un correo, mediante una App o un dispositivo hardware (por ejemplo, FIDO). Además, será recomendable que todos dispongan de sus claves únicas de seguridad autodestructibles.