¿Cómo son vuestros ciclos de actualizaciones o de subidas a producción?
!
- Categoría: Trabajar como desarrollador
Cuando se desarrolla un producto durante un tiempo y se tienen que ir incorporando mejoras cada cierto tiempo se suelen seguir unos ciclos de actualizaciones, comúnmente conocidas como subidas a producción. Pueden ser actualizaciones de una aplicación móvil, cambios en la web, cambios de software en un programa, etc…
Ordenar por: Más útiles | Recientes | Cronológico
10 Respuestas
-
!
Karma: 30 (1 voto)
En mi anterior empresa, las subidas a Producción se llevaban a cabo con la “asiduidad que los jefes querían”. Es decir, cuando ellos consideraban que era un buen momento para haber terminado un desarrollo, ponían una fecha y punto. Tanto si caía en viernes como en sábado.
En cambio, en la empresa que estoy ahora, las subidas a producción se realizan sólo cuando hay cierta cantidad de funcionalidades terminadas en entornos de preproducción, y teniendo siempre la premisa de no realizar las subidas en viernes, ni siquiera a principios de mes (que es cuando más gente hace uso de la herramienta desarrollada).
No hace falta que indique cuál de ambas alternativas prefiero.
-
!
Karma: 5 (0 votos)
para rails `cap deploy` y listo :)
-
!
Karma: 5 (0 votos)
Sync de Entorno Test > Prod, de ejecución automático y programado en una fecha y hora determinada.
-
!
Karma: 5 (0 votos)
En web lo subo en cuanto lo pruebo. Al fin y al cabo si falla solo hay que revertir.
En apps como tienes que tener en cuenta que no todo el mundo esta siempre 100% aztualizado suelo sacar actualizaciones cuando hay algo sustancial que merezca la pena.
-
!
Se me olvidaba decir que esto es cuando eres independiente. Cuando estas en una empresa cuando quiera el jefe…
-
!
Karma: 5 (0 votos)
En web
Si es un problema de funcionalidad de algo ya implementado, se soluciona y se de sube una vez.
Si es un nueva funcionalidad hasta que el jefe lo prueba.
-
!
Karma: 0 (2 votos)
¿Qué cómo son? ...pues un puto estrés, la verdad.
-
!
Karma: -12.5 (2 votos)
en mi actual empresa trabajamos con metodologías Agile, concretamente Scrum para el desarrollo del proyecto. el product owner nos marca los objetivos a partir de casos de uso, hacemos una valoración en tareas muy atómicas y empezamos sprints de 3 o 4 semanas. en cada sprint se genera una versión que en principio tiene funcionalidades cerradas y se puede llevar a pre-producción. cada cierto tiempo, una versión, con funcionalidades acumuladas durante varios sprints se lleva a producción. la resolución de bugs es continua en todos los sprints y no tiene sprints específicos.
-
!
Karma: 30 (1 voto)
En mi empresa actual, y debido al dinamismo habitual por la multitud de landings generadas a diario, los encargados de los pases a producción son los diseñadores y programadores, después que el cliente y responsable hayan dado su ok a los visuales/funcionalidades en el entorno de preproducción.
Si un despliegue a producción es crítico, nunca se realiza un viernes (por posibles problemas en fin de semana) o un lunes (por la sobrecarga de reuniones). Si el cambio no puede tener ocasionar colaterales, se puede hacer en cualquier momento.
-
!
Karma: 5 (0 votos)
Siempre fui independiente. Supongo que de haber tenido jefes podría contar anécdotas acerca de las decisiones extrañas que suelen tomar.
En mi caso la experiencia me demostró que cada modificación que se realiza, ya sea programada o a pedido del usuario, aporta “valiosos” nuevos errores. Así que se vuelven a probar las partes del programa que puede afectar. Y siempre aparece alguno, que se corrige. Aún así se filtran errores de vez en cuando, pero no son los más groseros.
Los clientes no entienden porqué para agregar 4 o 5 campos demoro varios días, pero prefiero eso a que me pongan en ridículo señalando un error tonto que apareció el día anterior, luego de funcionar perfectamente durante meses. Claro, curiosamente coincidió con su pedido de modificación “urgente”.
Mis ciclos pueden ser de horas o de semanas, pero siempre es “cuando está listo”.
-
!
Karma: 5 (0 votos)
Una vez que termino una versión o ciclo de desarrollo, sigo el siguiente workflow:
1- Cuando estoy desarrollando, trabajo en mi branch ‘development’.
2- Una vez que he terminado de desarrollar, mediante Grunt, creo una tarea que me compila mi código, hace unit testing, lo valida y minifica para pasarlo a producción, acto seguido hace un merge con master (que es la versión de producción) y comiteo ese branch específico a Heroku (para esto seteo que el origin de ese branch sea Heroku).
Y listo, así tengo mi sólido sistema de pasada a producción, con un código optimizado y rápido.
