Todo proyecto que entregamos pasa por GitHub: control de versiones, revisión de código y los pipelines de CI/CD que convierten un pull request mergeado en algo corriendo en Brova Cloud, automáticamente.
El mismo proceso de tres fases que usamos para todo lo que construimos: consultoría, construcción, operación. GitHub cambia lo que pasa dentro de cada fase, no la estructura.
Estrategia de branching, protecciones y accesos configurados antes del primer commit.
Nada llega a producción sin que otro ingeniero lo haya revisado.
Pipelines de CI/CD que testean, construyen y despliegan a Brova Cloud sin un paso manual que se pueda olvidar.
Una herramienta vale lo que valga la disciplina alrededor de ella. Esto es lo que realmente significa "usamos GitHub" en un proyecto.
Revisiones obligatorias, para que la calidad no dependa de la memoria o de buenas intenciones.
GitHub Actions corriendo tests y despliegues automáticamente en cada merge.
Vinculado directamente a los commits y pull requests que los resolvieron.
De quién desplegó qué, cuándo y por qué, para cada entorno.
Esto es lo que la gente suele querer saber sobre GitHub antes de escribirnos.
Sí, la protección de ramas hace que esto sea un requisito y no una sugerencia: nada llega a producción sin que otro ingeniero lo revise primero, así la calidad no depende de la memoria o las buenas intenciones de alguien en un día ocupado.
Totalmente, a través de pipelines de CI/CD armados con GitHub Actions. Los tests corren y los deploys a Brova Cloud pasan automáticamente en cada merge, sin un paso manual que alguien pueda olvidarse o saltear por apuro.
Tenés acceso. Todos nuestros clientes son dueños completos de su código, y el repositorio de GitHub, incluyendo su historial completo de quién hizo qué, cuándo y por qué, es parte de lo que se te da acceso durante y después del proyecto.
Se configura durante el armado del repositorio, antes del primer commit, según cuánta gente trabaja en paralelo y con qué frecuencia se hacen releases. Un proyecto en solitario y un equipo de cinco ingenieros necesitan enfoques de branching bastante distintos, así que no usamos un solo patrón sin importar el contexto.
Sí, el seguimiento de issues se ata directamente a los commits y pull requests que los resolvieron, así hay una línea clara entre que se reporte un bug y el cambio de código exacto que lo arregló, en vez de un tracker de bugs que vive desconectado del código.
O escribinos por WhatsApp, +44 7883 256391. Respondemos dentro de un día hábil.