JCeb's Blog

Programación, investigación, proyectos, vida y mas…

Posts Tagged ‘proyecto

Proyecto de Software colaborativo online

with 4 comments

Muchas veces sucede que decimos “vamos a trabajar en linea”, trabajar en línea es muy recomendable, pero hay que saber cómo hacerlo, ya que de ello depende el éxito de nuestro proyecto.

Existen herramientas sugeridas para hacer este desarrollo, personalmente recomiendo:

Un administrador de versiones

¿Qué es?, bueno el administrador de versiones sirve para que cuando programamos un código vayamos controlando el progreso que vayamos obteniendo conforme el paso del tiempo.

Administrador de versiones colaborativo
¿Qué es?, así como podemos controlar nuestro código por persona, puede ser que cada participante quiera controlar su progreso, pero además, plantiemos la siguiente pregunta:
¿Cómo le hacemos para que Juanito Perez me pase la parte que le tocó?, bueno para resolver ese problema podemos usar uno de muchos administradores de versiones colaborativos que hay, por mencionar algunos:

-GIT
-SVN(Subversion)
-CVS
-HG(Mercurial)

Con estos administradores de versiones colaborativo podemos responder la pregunta anteriormente planteada y resolvemos la administración de nuestro producto al ír generando versiones.

Administrador de proyectos
¿Qué es?, bueno el administrador de proyectos sirve para que allí se anoten y establezcan las tareas y responsabilidades por proyectos y por persona, tambien sirven para medir el progreso de un proyecto, en lo personal porqué los he usado recomiendo 2:

-Project Pier
-Active Collab

Wiki
Uno de los últimos sistemas para administrar contenido que han surgido, lo interesante en las wikis es que se pueden hacer contenidos colaborativos de manera muy sencilla.

¿Para que nos puede servir?, la wiki puede sernos de utilidad para expresar los objetivos del proyecto a las personas que se vayan incorporando conforme la marcha. También puede servirnos para colocar temas acerca de colaboraciones que cada integrante desee aportar, ha aportado y hacer documentación que ayude a los desarrolladores que en futuro se deseen integrar.

Lista de correos
La comunicación es muy importante, por ello debe existir una lista de correo, donde con enviar el mensaje a la lista, este se distribuye entre todos los integrantes de la lista y no es necesario mandar mensajes a cada persona del equipo de trabajo.
Las herramientas que puedo recomendar porqué las conozco son:
- Mailman
- google groups

Salas de conferencia
Muy bien en determinados momentos es necesario tener que vernos y hablarnos, por ello existen sistemas de conferencia como skype, dimdim, entre muchos otros para hacer conferencias por voz y/o video.

Administrador de bugs
Cómo ninguna herramienta es perfecta, es necesario tener un sistema para administrar los bugs que tanto usuarios como desarrolladores logren detectar, así también como sugerencias para el mejoramiento continuo del producto. Personalmente porqué estoy familiarizado recomiendo BugZilla, que es fácil de usar y muy completa funcionalmente.

Ejemplo práctico
Como no todo es simplemente explicar y ya con ello entenderan todo, aquí va un ejemplo práctico.

El proyecto se llama “test”

primero se crea el proyecto, uno del equipo lo crea y… ¿Cómo lo creo?, bueno simplemente basta con entrar a github.com y abrir la cuenta, luego nos dice github si queremos crear un nuevo repositorio, por lo que debemos llenar la información que se nos requiere y una vez realizado esto nos da las instrucciones github.com paso a paso.

Pero no nos dice nada más respecto a como trabajar con nuestro equipo.

Para poder trabajar en equipo debemos de realizar lo siguiente:

Cómo administrador
1. Ir al repositorio del proyecto en este caso llamado “test”
2. Presionar el boton que dice “admin”
3. Ir a la sección que dice “colaboradores”
4. Añadir al/los colaboradores

Como colaborador
1. Ir a las configuraciones de nuestra cuenta
2. Clic en donde dice Llaves SSH públicas
3. Clic en agregar llave pública ssh
… ¿Cómo creo mi llave publica?, bueno github nos dice cómo en estas ligas:
http://help.github.com/mac-key-setup/ para OSX
http://help.github.com/msysgit-key-setup/ para Windows
http://help.github.com/linux-key-setup/ Para Linux

4. Clonar el proyecto, esto se hace de la siguiente forma:
Se accede al sitio del proyecto por ejemplo:

http://github.com/julianceballos/test

Ahí dice en un cuadro la ruta a copiar y conectarse por medio de ssh, algo así: git@github.com:julianceballos/test.git
Así que para clonar el proyecto debemos hacer:

$ git clone git@github.com:julianceballos/test.git

Hecho esto debe de crearse una carpeta llamada test
5. Una vez clonado nuestro proyecto, podemos comenzar a hacer colaboraciones, como modificar los archivos existentes o crear nuevos archivos, por ejemplo si hemos creado un nuevo archivo o aun más, una carpeta con archivos dentro simplemente basta con hacer:

$ git add carpeta/*
$ git add archivo_nuevo

6. Establecer punto de resguardo, esto es una vez que digamos tener una etapa de nuestro desarrollo, lista, hacemos un commit, para que sirve el commit?, es como un punto de respaldo, siempre que querramos podemos navegar entre los commit y podemos ver como quedó nuestra aplicación en un momento determinado, para hacer commit solo basta con:

$ git commit -am 'he llegado a un punto de satisfaccion'

7. Subir los cambios o continuar trabajando. Cuando hayamos terminado una mejora en nuestra parte del proyecto podemos subir los cambios o continuar trabajando en local y hacer commits cada vez que sintamos que es necesario guardar un historico de nuestro desarrollo. Si en cambio sentimos que ya estamos listos para subir las mejoras porqué se acerca una fecha de revisión o algo, solo basta con hacer:

$ git push origin master

8. No olvidar antes de hacer un push, primero hacer un pull, es decir primero jalar el repositorio para comprobar que tenemos una versión de todas las fuentes actualizadas.

Hasta este punto todo bien, a excepción de cuanto no hacemos pull, dejamos de revisar las actualizaciones del repositorio, modificamos archivos que a otra persona le han correspondido, usamos el master para experimentar, etc. Usualmente si se distribuye bien el código por módulos, se puede tener durante el proceso de desarrollo una programación correcta y jamás habrá problemas, pero como bien dicen “Si hay la probabilidad de que suceda, sucederá”, así que veamos una manera de resolver el problema de incompatibilidades en las versiones, fechas y nombres de los archivos. Para esto existen las famosas RAMAS de desarrollo, por ejemplo:

Partamos de un tronco común que es este caso en github se llama MASTER, este tiene ramas(sip, como un árbol), las ramas pueden ser:

- MASTER
- Modelos
- Vistas
- Controladores

Pero Modelos puede tener ramas y esas ramas son los desarrolladores que participan en esta capa del proyecto, por ejemplo:

- MASTER
- Modelos
- Juan
- Emmanuel
- Paco
- Vistas
- Controladores

¿Y qué son las ramas?, simplemente son una copia de su origen, por ejemplo Emmanuel es una copia de Modelos, que a su vez Modelos es una copia de MASTER, lo que sucede es que Modelos es una composición de MASTER con código nuevo que se ha generado por el equipo dedicado a esa área, la rama Juan es una composición de MASTER+Modelos + Código que Juan ha agregado para evitar que haya incompatibilidades entre los código que sus otros compañeros estan escribiendo.
Para generar branches solo basta con hacer:

$ git branch myBranch

Para cambiar entre branches solo basta con escribir:

$ git checkout myBranch

Para ver en que branch nos encontramos:

git branch

Aparecerá marcada con un * la rama en la que nos encontramos.

Una vez programadas las cosas el administrador del proyecto es quien tiene que mezclar todos los códigos de los participantes, esto se hace con un merge:

$ git merge mybranch

Lo que sucede es que lo que se haya programado en mybranch se mezcla con lo que se tiene en el branch donde te encuentras ubicado.

Listo, hacemos push y ya quedó nuestro proyecto, basicamente eso estará sucediendo todo el tiempo, cada quien hace su parte, se mezclan y se lanzan por versiones.

Para establecer las versiones solo basta con hacer:

$ git tag -a v1.0 -m 'Test 1.0'

Para subir el tag:

$ git push origin v1.0

Para subir todos los tags:

$ git push origin --tags

Al bajar desde la página de Github todos los tags apareceran listados, disponibles para descargar el de tu preferencia.

Por otra parte, el wiki que tiene github es útil y nos evita tener que crear uno, para que sirve?, es posible ahí escribir todas las partes en que consiste el proyecto e incluso escribir a quien le corresponde cada parte, por otro lado no es la mejor manera, por lo que para asignar y autoasignarse tareas es preferible utilizar el project pier, la lista de correos es para ponerse de acuerdo y la wiki simplemente para escribir objetivos, las caracteristicas del producto por versión y muchas otras cosas, como el equipo de desarrollo, etc.

Los medios de comunicación sean de voz o video son geniales para tener reuniones pseudo presenciales con el equipo de desarrollo, para tomar desiciones sobre lo que se puede mejorar, agregar al producto, etc.

Bueno espero este post sea de utilidad, no es una guía definitiva, es para tener una ídea de como trabajar en equipo, en lo personal me ha servido todo lo mencionado y no he tenido probemas =). Saludos.

Written by JCeb

3 septiembre, 2010 at 11:36 pm

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.