Buenos días!
Os cuento, estamos 3 en una ofi como developers. Por ahora tenemos un servidorcillo (un i3 con Ubuntu) en la propia ofi llamemosle A. Hasta ahora, cada developer trabajaba con un proyecto, es por lo tanto que teniamos como source en nuestro IDE el path del servidor A (trabajamos en Windows con una unidad mapeada en mi pc que apunta al /var/www del servidor A). Cada noche se hace backups del /var/www en un hd externo.
Queremos mejorar todo este tinglado porque ahora tenemos un par de proyectos en el que trabajaremos dos a la vez. Hemos pensado en GIT (concretamente bitbucket) pero me gustaria saber como lo planteariais vosotros. Queremos/tenemos dos entornos actualmente: el de testing en el server A -aquí se conectan nuestros clientes para ver como va quedando su encargo- y el de producción, que suele ser un Servidor Dedicado que tenemos en Dinahosting.
A tener en cuenta: hay un pc (el mio!) que es un portatil y tanto trabajo desde dentro de la ofi como desde fuera, por lo que no puedo tener el origen de datos en mi IDE apuntando al /var/www del servidor.
Hasta ahora, en depende que proyectos tenia mi IDE configurado para que, al hacer un cambio automaticamente se subiera por FTP a la web en producción del cliente, por comodidad (automatic upload on save!). En depende que proyectos no puedo hacer esto :)
De momento solo esto, que no es poco!
Muchas gracias!
ps: ahora, cuando queremos subir los cambios realizados en el servidor A hacia el de producción solemos por FTP subir la carpeta entera cosa que es lenta y a veces nos hemos llegado a cargar algo en producción, es una chapuza, lo se, por eso quiero saber también que nos aconsejais! :)
Utiliza git sin ninguna duda. Bitbucket es una buena opción porque permite tener repositorios privados de forma gratuita, pero también podríais montar un Gitlab https://www.gitlab.com/ en un servidor vuestro.
Para despliegues os recomiendo utilizar alguna herramienta como Capistrano http://capistranorb.com/, Rocketeer http://rocketeer.autopergamene.eu/ o similares. Hay muchísimas, escritas en todo tipo de lenguajes y con distintos niveles de complejidad, es cuestión de probar. Casi todas permiten definir distintos entornos, así que es muy fácil separar los procesos de despliegue por entorno, y puedes hacer todo tipo de tareas, no solo subir código sino operaciones con servicios, caché, base de datos... lo que sea.
Git+Capistrano es un combo que funciona igual de bien tanto si se es una sola persona como si se trabaja en equipos con decenas de personas. Al final te verás moviendo muchísimo código con comandos simples y verás cuánto te frenaba el FTP. :)
Git con bitbucket está bien. Yo tendría una branch "master" y que cada uno trabaje en la suya luego mergeais a la master y cada dia o cada X tiempo cada unos hace un pull para tener lo mismo.
Para que los entornos sean idénticos nada mejor que usar unas maquinas virtuales con puppet o vagrant. Así cada desarrollador tiene lo mismo, preproduccion y produccion.
Para hacer los deploys a producción, nosotros tenemos un script que sube el tag que le indiquemos + ejecuta los cambios de la BBDD.
Hay muchas formas todo es encontrar la que os de menos trabajo y sea mas estable.
Nosotros en la ofi, somos 4 developers, y actualmente trabajamos con git mas bitbucket para proyectos privados de clientes, y github para liberar código :),
En cuando a ramas, trabajamos con 3 ramas; una para desarrollo, otra para el entorno pre-producción (donde ven los clientes su trabajo para validar cambios) y finalmente la de producción.
El flujo de trabajo seria el siguiente:
- Se realizan cambios y features completas en master, desde pre-producción (dev) realizamos un merge y subimos al servidor de pre-producción donde solo tenemos la trackeada la rama pre-producción (dev) por seguridad, en este entorno valida el cliente los cambios.
- Cuando los cambios están OK, desde producción hacemos merge de master, y subimos producción al servidor real, es decir, el de producción.
Para el servidor de pre-produccion, optaria por un VPS con bastante RAM y disco duro o un dedicado, donde subir la rama de pre-producción.
Hola, yo te propondría utilizar bitbucket para tener el código. Podríais intentar utilizar gitflow para trabajar, pero siendo 2,3 personas quizás se os haga un tanto complicado.
La idea para que todo fluya es tener una rama default/master y una rama llamada integración/develop. La rama default es producción solo se merge a cuándo se sube, la rama integración es donde vais trayendo los cambios y vais probando, hay que tratarla con cariño para que no se rompa.
Para trabajar sacas una rama desde default y realizas tus cambios, cuando veas que funciona mergeas sobre tu rama default para cerciorarte que tus cambios no tienen conflictos con la rama que esta ahora en producción y pruebas que no has roto nada.
Cuando todo este procesó esta integras a rama en integración y listo a otra cosa.
Cada vez que vayas a subir se prueba integración y se mergea con default y listo.
Parece muy costoso pero en el momento que Montás este procesó todo va bien.
No te agobies por los merge si utilizas Git.
Para subir siempre puedes utilizar capistrano o algo parecido. Verás lo sencillo que es subir con un comando.
Gracias por los comentarios! He sacado bastante info y cosillas a aprender. Antes que me respondierais investigue y encontré un script que tira de los hooks de bitbucket (o git) y va bien. Cuando uno de los developers de mi equipo hace un commit&push del proyecto, se actualiza nuestro servidor de pruebas (el que mira el cliente). Ahora estoy mirando si con capistrano, o parecido, podriamos hacer los deploy hacia el servidor de produccion de una forma mas rapida y comoda. Actualmente lo hacemos por ftp... ir sobrescribiendo controllers, models, views.. pero a menudo nos olvidamos algun fichero p.ej.
Ya hace unos meses de este post, pero a mí me ha venido genial. Estoy en una empresa pequeñita donde quiero implementar Git, de momento estoy trabajando yo solo con Git y Bitbucket, pero me faltaba la parte del deploy, con la info que habéis puesto aquí creo que seré capaz de afrontar todo este proceso. Muchísimas gracias!
Os cuento, estamos 3 en una ofi como developers. Por ahora tenemos un servidorcillo (un i3 con Ubuntu) en la propia ofi llamemosle A. Hasta ahora, cada developer trabajaba con un proyecto, es por lo tanto que teniamos como source en nuestro IDE el path del servidor A (trabajamos en Windows con una unidad mapeada en mi pc que apunta al /var/www del servidor A). Cada noche se hace backups del /var/www en un hd externo.
Queremos mejorar todo este tinglado porque ahora tenemos un par de proyectos en el que trabajaremos dos a la vez. Hemos pensado en GIT (concretamente bitbucket) pero me gustaria saber como lo planteariais vosotros. Queremos/tenemos dos entornos actualmente: el de testing en el server A -aquí se conectan nuestros clientes para ver como va quedando su encargo- y el de producción, que suele ser un Servidor Dedicado que tenemos en Dinahosting.
A tener en cuenta: hay un pc (el mio!) que es un portatil y tanto trabajo desde dentro de la ofi como desde fuera, por lo que no puedo tener el origen de datos en mi IDE apuntando al /var/www del servidor.
Hasta ahora, en depende que proyectos tenia mi IDE configurado para que, al hacer un cambio automaticamente se subiera por FTP a la web en producción del cliente, por comodidad (automatic upload on save!). En depende que proyectos no puedo hacer esto :)
De momento solo esto, que no es poco!
Muchas gracias!
ps: ahora, cuando queremos subir los cambios realizados en el servidor A hacia el de producción solemos por FTP subir la carpeta entera cosa que es lenta y a veces nos hemos llegado a cargar algo en producción, es una chapuza, lo se, por eso quiero saber también que nos aconsejais! :)
25/04/2014 13:52
Para despliegues os recomiendo utilizar alguna herramienta como Capistrano http://capistranorb.com/, Rocketeer http://rocketeer.autopergamene.eu/ o similares. Hay muchísimas, escritas en todo tipo de lenguajes y con distintos niveles de complejidad, es cuestión de probar. Casi todas permiten definir distintos entornos, así que es muy fácil separar los procesos de despliegue por entorno, y puedes hacer todo tipo de tareas, no solo subir código sino operaciones con servicios, caché, base de datos... lo que sea.
Git+Capistrano es un combo que funciona igual de bien tanto si se es una sola persona como si se trabaja en equipos con decenas de personas. Al final te verás moviendo muchísimo código con comandos simples y verás cuánto te frenaba el FTP. :)
25/04/2014 10:52
Git con bitbucket está bien. Yo tendría una branch "master" y que cada uno trabaje en la suya luego mergeais a la master y cada dia o cada X tiempo cada unos hace un pull para tener lo mismo.
Para que los entornos sean idénticos nada mejor que usar unas maquinas virtuales con puppet o vagrant. Así cada desarrollador tiene lo mismo, preproduccion y produccion.
Para hacer los deploys a producción, nosotros tenemos un script que sube el tag que le indiquemos + ejecuta los cambios de la BBDD.
Hay muchas formas todo es encontrar la que os de menos trabajo y sea mas estable.
25/04/2014 13:16
Nosotros en la ofi, somos 4 developers, y actualmente trabajamos con git mas bitbucket para proyectos privados de clientes, y github para liberar código :),
En cuando a ramas, trabajamos con 3 ramas; una para desarrollo, otra para el entorno pre-producción (donde ven los clientes su trabajo para validar cambios) y finalmente la de producción.
El flujo de trabajo seria el siguiente:
- Se realizan cambios y features completas en master, desde pre-producción (dev) realizamos un merge y subimos al servidor de pre-producción donde solo tenemos la trackeada la rama pre-producción (dev) por seguridad, en este entorno valida el cliente los cambios.
- Cuando los cambios están OK, desde producción hacemos merge de master, y subimos producción al servidor real, es decir, el de producción.
Para el servidor de pre-produccion, optaria por un VPS con bastante RAM y disco duro o un dedicado, donde subir la rama de pre-producción.
26/04/2014 09:32
La idea para que todo fluya es tener una rama default/master y una rama llamada integración/develop. La rama default es producción solo se merge a cuándo se sube, la rama integración es donde vais trayendo los cambios y vais probando, hay que tratarla con cariño para que no se rompa.
Para trabajar sacas una rama desde default y realizas tus cambios, cuando veas que funciona mergeas sobre tu rama default para cerciorarte que tus cambios no tienen conflictos con la rama que esta ahora en producción y pruebas que no has roto nada.
Cuando todo este procesó esta integras a rama en integración y listo a otra cosa.
Cada vez que vayas a subir se prueba integración y se mergea con default y listo.
Parece muy costoso pero en el momento que Montás este procesó todo va bien.
No te agobies por los merge si utilizas Git.
Para subir siempre puedes utilizar capistrano o algo parecido. Verás lo sencillo que es subir con un comando.
02/05/2014 22:48
En fin, a estudiar! Gracias mil!
14/11/2014 18:54