Share
En esta serie, analizamos las diversas prácticas que se utilizan en el desarrollo profesional de WordPress. En el artículo anterior, revisamos un conjunto de estrategias y material de referencia que son útiles al crear temas, complementos y aplicaciones basadas en WordPress..
En este artículo, analizaremos el control de versiones y las configuraciones ambientales que facilitan el desarrollo, la prueba y la implementación de nuestro trabajo para minimizar la cantidad de errores que se abren camino en las versiones finales de nuestro trabajo..
Este tema no es nada nuevo. De hecho, me atrevería a decir que la mayoría de los lectores aquí están familiarizados con Subversion y / o Git (especialmente con la popularidad de GitHub). Como tal, el punto de este artículo no es tanto dar un recorrido por los distintos sistemas de control de origen o hacer un caso para cuáles debería usar, pero está destinado a hacer un caso por qué Debe utilizar el control de código fuente y su relación con nuestros entornos..
Si eres completamente nuevo en el concepto de control de versiones, proporcionemos una definición simple a partir de la cual podemos trabajar para que todos estemos en la misma página:
El Control de versión es una instantánea de su código fuente en cualquier período de tiempo que le permite revertir cuando se introduce un error y trabajar en una nueva función sin romper el código existente.
Dentro de la comunidad de WordPress, las personas a menudo están divididas sobre si considerar o no temas y / o complementos de software o sitios web glorificados. Personalmente, creo que son una forma de software, ya que están sujetos a muchas de las mismas prácticas:
Con ese fin, el desarrollo y mantenimiento del trabajo específico de WordPress se debe tratar como tal y es un estándar de la industria para proporcionar un nivel de control de versión en el software.
Además, el control de versiones funciona de la mano con trabajar en su proyecto, probarlo y luego implementarlo en un servidor en vivo para que otros lo utilicen.
La mayoría de los desarrolladores están familiarizados con los diversos entornos, incluso si no utilizan la terminología exacta. Simplemente definido:
Suficientemente simple.
El problema es que cada uno de estos entornos también está estrechamente relacionado con el control de versiones de tal manera que cuando se administran correctamente, puede minimizar la sobrecarga de mantenimiento de las versiones e implementaciones de su trabajo..
El entorno de desarrollo es la máquina en la que realmente desarrolla su proyecto. Incluye una copia de WordPress, el servidor web, el servidor de base de datos, el IDE y las herramientas relacionadas que usa para construir su proyecto.
Este entorno particular es donde deberías estar haciendo frecuentes confirmaciones. Con esto, quiero decir que cada vez que realice un cambio significativo, ya sea una nueva característica, resolución de errores o algo similar, entonces debería estar ingresando código al repositorio..
Aquí, la ventaja es que puede revertir, identificar y distinguir fácilmente los cambios en caso de que algo salga mal durante el proceso..
Una vez que haya completado una cantidad significativa de cambios (donde usted o su equipo determinen lo que constituye "significativo"), entonces es hora de marcar el conjunto de cambios y desplegarlos en el entorno de prueba..
El entorno de ensayo es un servidor independiente que se parece al entorno de producción, pero se utiliza para probar el proyecto antes de liberarlo. Incluye la última versión del código, los datos de prueba y está destinado a que los usuarios evalúen el proyecto antes de lanzarlo. Ningún desarrollo debe ocurrir aquí.
Aunque aquí no debe ocurrir ningún desarrollo, no es raro tener varias herramientas de depuración en su lugar para generar mensajes de registro o revisar lo que entra y sale de la base de datos mientras se trabaja en el sitio.
Dado que los desarrolladores a menudo cometen un conjunto de cambios en el repositorio, deben ser probados. Aquí es donde el entorno de ensayo entra en juego. En términos generales, el entorno de ensayo suele corresponder a cualquiera que sea el último conjunto de cambios confirmados en el repositorio..
Pero esto plantea dos preguntas:
En primer lugar, esto es algo bueno, ¡significa que el entorno de transición ha cumplido su propósito! Además, nos da la oportunidad de revisar nuestro código fuente para determinar si se debe resolver un error o se debe introducir una nueva característica.
Y aquí es donde el control de fuente es útil.
Si se produce un error, puede inclinarse en la dirección de deshacer el cambio, pero en el entorno de ensayo no es necesario. En su lugar, simplemente localiza dónde está el error, lo resuelve, confirma el código y, a continuación, vuelve a implementar el código en el entorno de ensayo para realizar pruebas..
Repite este proceso hasta que no exista ningún error o, más exactamente, no puede encontrar ningún error..
Si no puede localizar ningún error, entonces esencialmente tiene lo que se conoce como una compilación estable. En este punto, puede etiquetar, o sellar, o etiquetar, o cualquier convención que ofrezca el sistema de control de origen, una versión de su código y desplegarla en el entorno de producción..
Por supuesto, existe la posibilidad de que se pueda descubrir un error después de implementarlo en el entorno de producción. En ese caso, se deben tomar medidas especiales..
El entorno de producción es sinónimo con el sitio en vivo. Aquí es donde los usuarios reales están creando, administrando e interactuando con datos reales. Ningún desarrollo debe ocurrir aquí.
Hay muy poco que hablar sobre el entorno de producción en lo que se refiere al desarrollo. Después de todo, esto no debe ser más que donde se implementa el código fuente para que otros lo utilicen.
Pero existe la posibilidad de que se pueda lanzar un error aquí. Cuando esto pasa, esta es cuando debe ocurrir una reversión. En pocas palabras, una reversión es cuando toma el último conjunto de cambios y literalmente deshace la implementación restaurando el proyecto a su estado anterior.
Antes de realizar una reversión, vale la pena anotar los pasos de recreación para que pueda reproducirla tanto en el entorno de transición como en el de desarrollo para resolver el problema correctamente..
A partir de aquí, realice el desarrollo que se necesita para resolver el problema, cometer otro cambio, implementarlo en el entorno de transición e implementarlo en el entorno de producción, asumiendo que pasa la prueba.
Obviamente, esta publicación en particular cubre conceptos de alto nivel: no estamos explorando qué sistemas de control de versiones son mejores ni tampoco qué herramientas son mejores para su sistema operativo en particular. Estos temas están fuera del alcance de este post y cada uno merece su propia serie..
Sin embargo, dentro del concepto de desarrollo profesional de WordPress, estas prácticas obviamente pueden ser útiles en el desarrollo, prueba e implementación (y retroceso) de las versiones de su proyecto..
En la publicación final, analizaremos algunas de las diversas herramientas disponibles que nos permitirán diagnosticar muchos errores en nuestro entorno de desarrollo local con la intención de evitar que muchos de ellos incluso lleguen al entorno de transición..
Accentsconagua