josejfernandez
Software Architect
- Registrado
- 1 Ago 2012
- Mensajes
- 525
- Puntos
- 63
No entiendo tanta hostilidad, de verdad...
Normalmente se desarrolla en local. Hay bastantes motivos para hacerlo:
Generalmente tendrás 3 zonas a la hora de desarrollar:
Tampoco es estrictamente necesario el VPS para los despliegues. Puedes hacerlo todo localmente (pierde la magia del despliegue remoto, pero está bien).
Por ejemplo, yo desarrollo una aplicación web que depende de un webservice que tira de la misma base de datos para dar servicio a clientes (los clientes son un plugin de WordPress, un módulo de Prestashop...). Todo corre en mis máquinas locales (normalmente en el sobremesa, pero a veces también en un portátil -Atom :meparto
: la aplicación, el WordPress, el PrestaShop y el webservice.
Voy desarrollando localmente, haciendo los commits pertinentes y de cuando en cuando hago push hacia mi Bitbucket, Github o el que corresponda en cada caso. Cuando quiero desplegarlo todo, y aquí viene la parte interesante, desarrollé unos scripts que he colocado en el servidor de producción (que en este caso sí es un VPS, pero desde el punto de vista de desarrollo lo trato igual que si fuera Bitbucket, como cualquier repo remoto) y que, al recibir commits mediante un push, realizan el despliegue de cada repositorio de forma automática: ejecutan los SQL de actualización, modifican el código en producción con lo que yo envío como código estable, eliminan ficheros antiguos que ya no se usan...
En todo ese workflow sólo necesito el VPS para que se vea en Internet, pero antes de tener un VPS lo hacía en local del mismo modo. Lo que te interesa, más que el equipamiento o infraestructura, es el workflow, tu flujo de trabajo, la forma en que mueves el código que sale del horno al entorno de producción. Y en eso es más importante cómo usas Git y cómo haces el despliegue que si tu VPS está en uno u otro proveedor.
Si lo quieres para probar, te da lo mismo cuál sea, mientras cumpla con lo mínimo (no esperar milagros al desplegar cosas complejas en un VPS lentorro). Si lo quieres para producción, entonces es otra historia.
Aquí tienes una guía -en inglés- donde te explican las metodologías, herramientas y flujos de trabajo que se utilizan a día de hoy para desarrollar: http://www.smashingmagazine.com/2015/07/development-to-deployment-workflow/ y puedes encontrar más opciones buscando en Google: https://www.google.es/search?q=development+workflow+php+deployments
Verás que en casi todos los casos, el tema va por ahí (desarrollo local, local/staging/producción, máquinas virtuales, etc).
Por supuesto, puedes simplemente ponerte un VPS, utilizar el Notepad++ (y no un IDE de verdad :wtf y sincronizar con el FTP, pero eso no te diferenciaría en nada de millones de programadores chapuceros que suben cagadas una y otra vez al código que está funcionando y que tienen que tirar de backups más a menudo de lo que les gustaría. Lo he visto demasiado -y no soy nada viejo, al contrario- como para no preferir prevenir que curar a estas alturas xD
PD: por cierto, para que aprendas PHP como debe ser http://www.phptherightway.com
Normalmente se desarrolla en local. Hay bastantes motivos para hacerlo:
- Evitar conflictos con el código en producción. Si modificas directamente el código que está funcionando, ¿cómo vas a depurarlo? Primero se desarrolla, luego se ejecutan los tests, se comprueba que tus cambios son estables, y entonces lo subes/despliegas. Pero no trabajas directamente sobre el código en producción. Sé que me dirás que sólo estás haciendo pruebas, pero ese flujo de trabajo es una mala práctica, y hacerlo de este modo es todo lo contrario. Si estás aprendiendo es razonable que aprendas del mejor modo posible, ¿no? Por ello... Evita eso de sincronizar con el FTP, editar el remoto directamente, etc.
- Utilizar las herramientas adecuadas. Si utilizas un FTP/SCP/rsync/loquesea para mantener la sincronía entre versiones (local, remoto/producción), estás intentando solucionar el problema de gestionar las versiones con herramientas que no fueron diseñadas para ello. Ese problema lo resuelve Git de una forma eficaz y segura. Y no cuela lo de "es que lo mío es simple", ya borrarás algo sin querer y tendrás que recurrir a commits antiguos de Git. Te alegrarás de no haber sincronizado la cagada con el server de producción. Shit happens, a todo el mundo puede pasarle. El otro día en el IRC de desarrollo web en Freenode, un tío lamentándose no saber más de Git porque no sabía sacar un commit antiguo y se había cargado todo -y reescrito commits- xd
- Trabajar en local no te limita en nada. Especialmente, y relacionado con el primer punto, eres libre de romper lo que quieras, de dejar el código en un estado inestable, de programar algo ineficiente que saturaría el servidor de producción... Te centras en que funcione y luego ya lo mejorarás. Puedes crearte una rama local nueva en Git para hacer eso, que no tiene por qué estar en el servidor de producción.
Generalmente tendrás 3 zonas a la hora de desarrollar:
- Local. Donde sucede la magia de la programación. Por local entendemos las máquinas de desarrollo (tu portátil, tu sobremesa, el equipo de tu pareja en el que haces ñapas cuando se te ocurren en el momento), no necesariamente un único equipo. Git te permite gestionar las versiones que vayan surgiendo, ya lo sabes.
- Staging / desarrollo. Aquí tendrías tu repositorio remoto de Git. En tu caso, Bitbucket. Si ya lo utilizas, entonces entiendes el concepto. También puede ser otro tipo de servidor (VPS, por ejemplo) donde tienes una demo visible del software corriendo.
- Producción. Donde tu código se está ejecutando mientras tú desarrollas versiones nuevas, mientras duermes y mientras lees esto. Y ese código sólo debería ser modificado cuando tus cambios (generados en local y almacenados en staging) son estables y llega el momento del... ¡Despliegue! Aquí puede ser un VPS también. Y es más guay si es un VPS, de hecho.
Tampoco es estrictamente necesario el VPS para los despliegues. Puedes hacerlo todo localmente (pierde la magia del despliegue remoto, pero está bien).
Por ejemplo, yo desarrollo una aplicación web que depende de un webservice que tira de la misma base de datos para dar servicio a clientes (los clientes son un plugin de WordPress, un módulo de Prestashop...). Todo corre en mis máquinas locales (normalmente en el sobremesa, pero a veces también en un portátil -Atom :meparto
: la aplicación, el WordPress, el PrestaShop y el webservice.Voy desarrollando localmente, haciendo los commits pertinentes y de cuando en cuando hago push hacia mi Bitbucket, Github o el que corresponda en cada caso. Cuando quiero desplegarlo todo, y aquí viene la parte interesante, desarrollé unos scripts que he colocado en el servidor de producción (que en este caso sí es un VPS, pero desde el punto de vista de desarrollo lo trato igual que si fuera Bitbucket, como cualquier repo remoto) y que, al recibir commits mediante un push, realizan el despliegue de cada repositorio de forma automática: ejecutan los SQL de actualización, modifican el código en producción con lo que yo envío como código estable, eliminan ficheros antiguos que ya no se usan...
En todo ese workflow sólo necesito el VPS para que se vea en Internet, pero antes de tener un VPS lo hacía en local del mismo modo. Lo que te interesa, más que el equipamiento o infraestructura, es el workflow, tu flujo de trabajo, la forma en que mueves el código que sale del horno al entorno de producción. Y en eso es más importante cómo usas Git y cómo haces el despliegue que si tu VPS está en uno u otro proveedor.
Si lo quieres para probar, te da lo mismo cuál sea, mientras cumpla con lo mínimo (no esperar milagros al desplegar cosas complejas en un VPS lentorro). Si lo quieres para producción, entonces es otra historia.
Aquí tienes una guía -en inglés- donde te explican las metodologías, herramientas y flujos de trabajo que se utilizan a día de hoy para desarrollar: http://www.smashingmagazine.com/2015/07/development-to-deployment-workflow/ y puedes encontrar más opciones buscando en Google: https://www.google.es/search?q=development+workflow+php+deployments
Verás que en casi todos los casos, el tema va por ahí (desarrollo local, local/staging/producción, máquinas virtuales, etc).
Por supuesto, puedes simplemente ponerte un VPS, utilizar el Notepad++ (y no un IDE de verdad :wtf
y sincronizar con el FTP, pero eso no te diferenciaría en nada de millones de programadores chapuceros que suben cagadas una y otra vez al código que está funcionando y que tienen que tirar de backups más a menudo de lo que les gustaría. Lo he visto demasiado -y no soy nada viejo, al contrario- como para no preferir prevenir que curar a estas alturas xDPD: por cierto, para que aprendas PHP como debe ser http://www.phptherightway.com
