Buenas a todos.
Tengo una pregunta, En Consulneo tenemos ya la idea de comenzar a desarrollar una aplicación completa con V7, comenzando desde lo más pequeño, hasta lo más complicado.
Pero queremos saber, si con el servidor que está en la nube, se puede trabajar en equipo, osea varios desarrolladores. O con este servidor no se puede?
Si es posible trabajar en equipo, cómo se hace ?
Saludos
Hola.
Para trabajar en equipo necesitas:
- Tener tantas licencias de edición como usuarios vayan a desarrollar simultáneamente. En el caso del servidor de la nube, un nivel 1 tiene 1 licencia de edición PaaS, y un nivel 2 tiene 2. Cada licencia de edición en PaaS adicional son 150 €/mes más (según la tarifa actual). Así, un nivel 2 puede tener a dos desarrolladores siimultáneos en su servidor de la nube.
- Cuando dos desarrolladores están trabajando simultáneamente, pueden trabajar en la misma solución, pero no en el mismo proyecto. Si uno de ellos abre un proyecto y quiere cerrarlo para que trabaje el otro, tiene que utilizar la opción "Deshacer desprotección de proyecto" del vDevelop.
A partir de ahí, tendréis que elaborar un protocolo de trabajo (división de la aplicación en proyectos, para que cada uno se dedique al suyo, establecimiento de la estructura de datos previa, etc.).
Saludos,
Fran Varona
Gracias...
Saludos.
Hola, retomo el hilo ya que estoy interesado en conocer maneras de desarrollo en equipo con V7. Vamos, experiencias de quienes ya lo hayáis hecho ¿cómo os lo habéis organizado?
Encontré un post que trata el tema explicando una posible forma la cual, a priori, es la misma que había pensado en un primer momento pero la idea de separar los proyectos atendiendo al número de desarrolladores en vez de a razones puramente de análisis y diseño, no sé... ¿cómo lo veis? ¿cómo lo hacéis?
Gracias de antemano, ¡saludos!
Con respecto a la protección contra edición por caja y no por objeto tengo dudas para Velneo:
1. ¿Por qué no permitir ediciones concurrentes dentro de una misma caja? ¿Por qué no aplicar el bloqueo a nivel de objeto?
2. Soy consciente de que algo así incrementa la complejidad y pone en juego la integridad del proyecto. Implementar una funcionalidad así no es trivial pero ¿tenéis planeado hacerlo o ya habéis visto que algo así sería contraproducente/inviable?
3. Al final todo se resume en un sistema de control de versiones integrado en vDevelop con cierta potencia: permitir "Nº de historia" (revisiones) por objeto, diferencias encontradas entre revisiones arbitrarias del mismo objeto, posibilidad de mezcla de cambios o algún mecanismo del estilo para permitir incluso edición concurrente del mismo objeto (sin bloqueo/protección), posibilidad de hacer los típicos comandos análogos en otros controles de versiones centralizados como SVN por ejemplo (checkout, commit, update, revert, log, ...). Seguramente esté pidiendo la luna :) pero... ¿sería posible un "vSCM" integrado en vDevelop? :-)
Saludos!
Buenas.
Una forma que hemos utilizado para la realización de la vConta es tener cada uno una caja en el nivel mas alto.
Cuando acabamos bajamos los objetos a su caja respectiva.
Un saludo.
Jorge Velasco Fernández
jvelasco@theseedsc.com
www.theseedsc.com
@Ofsantana
Uno de mis proyectos tiene la siguiente estructura:
Más vale una imagen...
saludos
Antonio Vela
¡Hola de nuevo! Siento ser un tanto pesado con este hilo pero seguimos sin conseguir una arquitectura de cajas lo suficientemente cómoda para trabajo en equipo.
El trabajo en equipo se puede resumir en crear (1) nuevos bloques/objetos de programa y en (2) modificar/ampliar/corregir bloques/objetos existentes y finalizados. Estamos utilizando la estrategia propuesta en el blog de Velneo (y recientemente este post que habla del tema) y nos funciona bastante bien para el punto (1) pero para el (2) la cosa ya no es tan cómoda; y a medida que crece el proyecto peor.
Adjunto una imagen de cómo lo tenemos organizado ahora mismo (vscrum_arch_1.png). En el proyecto de aplicación principal (vScrum) existe una carpeta "Pendientes de revisión". La idea es que los proyectos de aplicación de cada desarrollador queden vacíos una vez terminan con sus tareas, y los muevan a dicha carpeta "Pendientes de revisión" en la que me estoy encargando de comprobar objeto por objeto, revisando posibles fallos (aunque cada miembro del equipo prueba todo lo que hace antes de moverlo a revisión) y validando que se cumple con las reglas de estilo. Finalmente todo lo existente en "Pendientes de revisión" se reorganiza en sus respectivas carpetas en el proyecto y esta carpeta también debe quedar vacía en cada fin de ciclo.
El problema es que una vez colocamos objetos en la caja de abajo, no conseguimos encontrar una solución cómoda para poder subirlos de nuevo arriba cuando queramos volver a trabajar con ellos y permitir mantener protegido el proyecto principal para que otra persona pueda meterse en ella y mover a su caja los objetos con los que desee volver a trabajar.
Por ahora la única solución que se me ocurre es cambiar momentáneamente la dirección de la herencia, de modo que se muevan los objetos de abajo a la caja de arriba que sea y, posteriormente, reestablecer la relación de herencia original. Luego se lleva a cabo la modificación y se vuelve a mover al proyecto principal, a la carpeta de Revisión.
Otra opción sería la siguiente pero no es posible (vscrum_arch_2.png). Las rayas esas discontinuas cutres (Paint power!) las he metido yo jejeje. La idea sería tener un proyecto de aplicación "limbo" que contuviera tres directorios "Lucas", "Pablo", "Quique" de manera que cada desarrollador moviera sus objetos a su respectiva carpeta en el proyecto Limbo. A este proyecto se entraría solamente para posteriormente mover de ahí a su proyecto de aplicación personal, de manera que el limbo también quede protegido en todo momento para el resto de desarrolladores. Esta solución no es viable porque este tipo de "herencia cíclica" no es legal :-)
Quizá adoptar la solución propuesta en vscrum_arch_2.png y realizar los cambios de herencia desde ahí. Aunque sería menos cómodo incluso porque implica cambiar varias herencias y luego reponerlo todo.
La solución de velavisual le pasa un poco lo mismo. Si cada desarrollador se va a encargar de su/s módulo/s o partes concretas del programa, y nadie más tocará dichas partes, entonces es buena solución partir de "arriba hacia abajo" y tener modularizado el programa en varios proyectos. Pero cuando todos se encargan de todo entonces vuelves un poco a lo de antes.
¡Necesito más ideas! :-D y gracias por aguantar la chapa jejeje ¡Un abrazo!
[attachment=12330,1126] [attachment=12330,1127]
Hola.
Si no has batido el record del mensaje más largo, cerca está ;-).
Lamento no poder ayudarte, porque no me ha tocado intentar desarrollar en equipo. Aunque sería una gran, gran, gran ayuda, creo que el bloqueo por objeto y no por caja no es una opción, por necesidades del diseño. Yo trabajé con alguna aplicación para desarrollo en grupo en lenguajes de programación "tradicionales" y son una pasada (aunque, claro, no manejaban objetos interrelacionados, sino simples líneas de programa).
Quizá los que más te puedan ayudar sean los propios de Velneo, pues parece que ellos sí que trabajan de esta manera, o al menos así lo contaron en la presentación de vGestion.
Ya, no he aportado mucho, pero simplemente quería decir... lo he leído, y mucho ánimo!
Saludos,
Fran Varona
Hola Enrique
Te cuento nuestra experiencia, aún que no se si te servirá de algo, ya que debeis encontrar la forma mas comoda para vosotros.
Nosotros estando tres personas en la misma solución y en ubicaciones distintas no usamos un proyecto por persona, ya que lo probamos al principio y es viable en proyectos sencillos, pero no en soluciones complejas. Te evita tener un proyecto abierto mientras creas los objetos, pero te obliga a crear los objetos de interface para cada desarrollador, y en nuestro caso la interface tambien es compleja.
Tu idea de vscrum_arch_2.png podría solucionar esto en parte, pero aún así tendrias el problema de volver a subir los objetos etc... (copiar y pegar funciona, pero provoca bastantes errores humanos)
Lo que nosotros hacemos es repartir el trabajo por módulos, si uno está en el nucleo otro está en gestión y otro en interface, el único problema es a la hora de reiniciar si otro está en ejecución, pero para eso esta el telefono, mail, skype etc...
Otra cosa que hacemos es usar las soluciones compartidas, casi todos los proyectos tienen una caja de datos y otra de aplicación, y heredan las soluciones que necesitan.
Para lo que comentas de revisar el trabajo de los demás tenemos otra alternativa, cada 2 o 3 horas nos enseñamos mutuamente lo que acabamos de hacer, en edición y en ejecución, y tal vez sea el tiempo mejor invertido, ya que surgen bugs, ideas, soluciones etc...
Un saludo
Hola. Muchas gracias por las sugerencias y los ánimos :-) Cualquier cosa nos puede venir bien. Gracias innovadb (hola Hugo & Ricardo!) por comentar cómo lo hacéis porque voy a proponer adoptar las ideas que aportáis a mis compañeros.
La idea del "limbo" por ahora deshechada por lo comentado. La modularización junto con el uso de soluciones compartidas es a lo que tarde o temprano había que llegar. Estamos "migrando" (bueno, reanalizando/reescribiendo de cero) una aplicación que tenemos en V6 a V7, el tema de la modularización, uso de soluciones compartidas comunes y aprovechamiento de la herencia tenía pensado ponerme más serio a partir del siguiente programa que pasemos de V6 a V7 (mes que viene seguramente) pero parece que ya ha llegado el momento, mejor ahora y ahorrar tiempo :)
Hagamos lo que hagamos lo comentaré por aquí por si le sirve a más gente o me tiráis de las orejas por la animalada que vaya a cometer XD
Un saludo