Información general
En los últimos 20 años hemos desarrollado un proceso que nos ayuda a satisfacer a nuestros clientes. Este proceso consta de ocho partes, todas ellas igualmente importantes. Durante años, hemos creado nuestras propias herramientas para facilitar la mayor parte de este proceso. Pero ahora existen excelentes herramientas comerciales que os animamos a utilizar.
Nuestro proceso de desarrollo de software, al igual que los demás procesos, es un ciclo. Así que podemos empezar en cualquier fase.
El ciclo
Como esta guía es para desarrolladores, empecemos por escribir código.
Escribir código
Escribir código es lo que nosotros, como desarrolladores de software, pasamos mucho tiempo haciendo. Tenemos nuestro IDE favorito abierto, escribimos código, depuramos, resolvemos problemas. No conocemos a ningún desarrollador de software al que no le guste resolver problemas.
Cuando tenemos algo, lo enviamos (commit) a nuestro sistema de control de versiones…
Enviar
Enviamos código a un Sistema de control de versiones. En nuestro caso, utilizamos git con GitHub. Existen muchos otros sistemas de control de versiones. Antes usábamos Subversion, pero ahora usamos GitHub. GitHub es compatible con muchas otras herramientas y tiene una API muy completa. Pero hay otros que se pueden tener en cuenta: BitBucket, Mercurial, etc.
Si no utiliza ningún control de versiones, por favor, empiece ya. Ahora es muy fácil. Permite volver a otras versiones del software antes de introducir un problema. Ayuda a colaborar en equipo. Es necesario para cualquier tipo de automatización de la compilación. ¿Hemos mencionado que es fácil?
Como desarrolladores, utilizamos una versión modificada de GitHub Flow para crear y fusionar solicitudes de extracción (pull requests) en nuestra rama principal (master branch).
Después de enviar el código, lo compilamos…
Compilar
Además de compilar en nuestros escritorios, tenemos servidores dedicados de TeamCity que compilan constantemente el código y verifican que funciona en la rama master en GitHub. Así nos aseguramos de que no haya errores y todos los demás puedan obtener el código más reciente y compilar.
Estos servidores TeamCity verifican cada envío (commit) y también crean nuestras versiones diarias cada cuatro horas aproximadamente. También crean nuestras versiones públicas WIP y Service Release.
Con cada nueva compilación, realizamos pruebas (test)…
Probar
Cuando los desarrolladores corrigen errores y solucionan problemas, nuestro personal interno de pruebas se asegura de que la versión pública funcione correctamente. También confiamos en nuestros clientes para probar las versiones WIP y Release Candidate.
Las pruebas se realizan antes y después del siguiente paso: publicar (publish)…
Publicar
Cuando tenemos una compilación lista para enviar a los clientes, la implementamos (o publicamos).
Esto incluye la publicación de…
- Instaladores descargables
- SDK
- Documentación (este sitio web)
…y el envío de anuncios públicos por correo electrónico, blogs y redes sociales.
Escuchar
Escuchamos de todas las formas posibles:
- Chat
- Correo electrónico
- Soporte telefónico +34 933 199 002
- Foro (Discourse)
Y a menudo, cuando escuchamos, encontramos problemas que hay que solucionar. A veces son pequeños… a veces son ENORMES. Siempre registramos un problema…
Registrar
Registramos los problemas en YouTrack y hacemos seguimiento.
YouTrack nos funciona bien porque nos ayuda a garantizar que cada problema se prueba y documenta adecuadamente.
Priorizar
Averiguar cuáles son las prioridades es DIFÍCIL. Hablamos con nuestros clientes. Hablamos entre nosotros. Utilizamos Gmail, Google Drive y Google Docs para comunicarnos. Chateamos 24 horas al día en Slack.
Nos reunimos los martes de cada semana. Antes de reunirnos, compartimos lo que hemos hecho en un Google Doc. En ese documento, compartimos los objetivos de cada producto que vamos a lanzar y cada grupo de funciones en las que estamos trabajando, incluimos gráficos de nuestro progreso y enlaces a nuestros problemas YouTrack, y recibimos informes verbales de persona que trabaja en las funciones.
Además, cada desarrollador escribe en qué ha estado trabajando, qué tiene previsto hacer a continuación y qué le impide completar su trabajo.
Automatizar
Y por último, pero no por ello menos importante, hacemos MUCHA automatización.
Algunas de las cosas que automatizamos:
- Compilar cada envío o commit de cada desarrollador antes de que pase a la rama master de desarrollo.
- Cerrar incidencias en YouTrack cuando los servidores de TeamCity fusionan las correcciones en nuestra rama master de desarrollo.
- Compilar versiones internas y públicas en nuestros servidores de TeamCity.
- Publicar nuevas versiones WIP escribiendo un comando en Slack.
- Subir versiones públicas a nuestros servidores de descarga.
En público
Hasta hace poco, estas son las partes de nuestros procesos que hemos hecho públicas:
- Probar
- Publicar (al menos se ve lo que publicamos)
- Escuchar
Y en los últimos dos años, hemos hecho público nuestro gestor de incidencias al cambiar a YouTrack. Algunas cuestiones las ocultamos al público por motivos de seguridad o privacidad de los usuarios.
Lo que nos gustaría hacer pronto es hacer aún más pública esta información:
- Compartir parte de nuestro código como repositorios públicos en GitHub para que los desarrolladores tengan ejemplos de código reales con los que trabajar.
- Permitir a los desarrolladores compartir correcciones y mejoras de nuestro código.
- Facilitar la creación de proyectos de plug-ins publicando RhinoCommon como paquete NuGet.
- Ayudar en la automatización de compilaciones cuando sea necesario.
