Bitbucket 4.9 y Bitbucket Data Center 4.9 colocan en primer plano las estrategias empleadas por los equipos para comunicarse con su código fuente. ¡Aprende tres nuevas estrategias fundamentales para ayudar a los equipos a trabajar de la forma que ellos quieran!
Que la recuperación en caso de desastre sea parte de tu plan estratégico
En el caso de las herramientas como Bitbucket Data Center que se utilizan para procesos complejos, la recuperación ante desastres (DR) pasa de ser de una herramienta a una verdadera estrategia ya que, si la gestión principal falla (lo que conocemos como “desastre”), los equipos necesitan de una herramienta que les permita continuar trabajando con la información. Aquí es donde DR entra en juego. El DR le permite a los clientes de Bitbucket Data Center hacer una réplica del estado de su instancia primaria a una “instancia en espera” que estará ubicada en otro sitio. Por lo tanto, si su instancia primera falla, Bitbucket Data Center lo pone en espera.
La instancia en espera es un ejemplo de plan de recuperación ante desastres (PDR) en el cual las instancias de Bitbucket en espera, se “congelan”, pero el servidor de archivos , base de datos y ElasticSearch (servidor para la indexación y búsqueda de contenido) se mantienen activos para que, de esta forma, se lleve a cabo la réplica.
Luego de que su sitio en espera contenga una indexación clonada de Bitbucket y una copia de su base de datos (plugins fundamentales) su equipo podrá rápidamente volver a poner todo en funcionamiento. En Atlassian utilizamos este modelo porque tenemos instancias en diversos sitios del mundo, por lo que si, por ejemplo, la instancia primaria de Sidney falla, podemos acudir a la herramienta de DR para efectuar la instancia en espera en San Francisco durante el pequeño lapso de tiempo de inactividad.
El haber agregado este sistema a Bitbucket Data Center le permite a los equipos y a las compañías poner en marcha un conjunto de herramientas para configurar mediante una estrategia proactiva las fallas que se produzcan, evitando que los prospectos a desarrollador que no están trabajando se conviertan en un problema. De esta manera, los administradores y técnicos en vez de preocuparse por eso se enfocan en las razones de la falla.
Elija cómo combinar sus pull requests utilizando estrategias de fusión
Mientras el DR y la copia de respaldo “cero” ayudan a los equipos y a las compañías mediante estrategias para el tiempo de inactividad, Bitbucket Server 4.9 introduce una nueva herramienta específica para hacer fluir el trabajo y codificar estrategias de revisión, algo conocido como estrategias de fusión o integración. Sus chequeos de complementos combinatorios han estado disponibles en el servidor Bitbucket de forma momentánea; sin embargo, las estrategias de fusión pueden dar a los usuarios y a equipos el control sobre cómo fusionar los pull requests en lugar de sólo intentar fusionarlos.
Los diferentes equipos tienen diferentes objetivos a la hora de rastrear a sus repositorios. La mayor parte del tiempo se prefiere usar Bitbucket cuando se quiera fusionar al cerrar un pull request, pero hay buenas razones para no deber hacerlo en algunas ocasiones. Por ejemplo, algunos equipos tienen una visión diferente sobre qué constituye un historial limpio, y sólo pretenden utilizar estrategias de fusión de “Avance Rápido” (fast forward).
Ahora un administrador de repositorio puede elegir cómo utilizar las estrategias de fusión y especificar qué alternativa de estrategia estará disponible para ser elegida a la hora de fusionar, lo que significa que quien fusione los pull requests puede tener el control total sobre la estrategia empleada. Podríamos tomar como ejemplo en estos casos el uso de un modelo Gitflow de ramificación. Se podría establecer una acción determinada para eliminar la fusión, no obstante se puede emplear “no-ff” (no fast forward, no avance rápido) para que se lleve a cabo adecuadamente el commit o ejecución de la fusión entre las ramas (branches) descargadas. Esta particularidad en el trabajo del equipo, o mejor dicho, esta función en el examinador predeterminado, le da a los equipos una funcionalidad única para trabajar de la forma que quieran.
Importar repositorios desde otros servicios de alojamiento
Comenzar un nuevo proyecto que requiera de la migración de repositorios en grandes cantidades desde un producto a otro o desde un servicio a otro no debería tener “fricción”. Así que, en vez de escribir scripts o importar repositorios uno a la vez, la nueva opción de importar varios repositorios tanto para Bitbucket Server como para Bitbucket Data Center les da a los equipos la habilidad de probar datos reales o de demostración.
Esto es de suma importancia sobre todo cuando se está comenzando con Git y servidor de Bitbucket o hacer un código a partir de un proyecto ya existente desde una nube de Bitbucket, Github.com, GitHub Enterprise o un servidor de GIT. Es rápido, es fácil, y le da a los equipos la flexibilidad para trabajar con datos a partir de la fuente que ellos quieran.
Todas las nuevas opciones publicadas en el servidor Bitbucket 4.9 y Bitbucket Data Center 4.9 ayudan en la colaboración de los equipos por medio de estrategias en curso. El haber agregado DR a Bitbucket Data Center es importante para cualquier actividad en el día a día de los equipos. Las herramientas son empresariales y/o de misión crítica, por lo que no se puede detener el trabajo durante un desastre o período de inactividad. En el área de los pull requests, los diferentes equipos así como diferentes repositorios podrán querer utilizar diferentes estrategias de fusión. Es precisamente con esta clase de herramientas que Bitbucket Server y Bitbucket Data Center pueden ayudar a su equipo y empresa a diseñar una estrategia de acuerdo al nivel de su equipo así como ayudar a los equipos a trabajar mejor en conjunto.
En caso de que te lo perdiste
Desde Bitbucket 4.5 se han agregado funcionalidades, se ha mejorado la experiencia de los pull requests y mucho más.
- Busqueda por Código (4.6): Ahora se puede buscar un código de forma directa en la barra de búsqueda, lo cual también se puede llevar a cabo ejecutándose entre todos sus proyectos y repositorios. También se puede detallar más la información sobre la búsqueda de código en un proyecto o repositorio específico. También existe la opción de buscar operadores para obtener resultados de búsqueda más precisos y para poder buscar el código en el alfabeto que esté escrito.
- Revisión a nivel de Commit (4.8): Esto permite que se pueda ver el fichero de diferencias antes de realizar la acción decommit, y además, otorga la facilidad de comentar en los pull requests para ayudar a los examinadores a hacer lo mismo; revisar los commits que han sido incorporados a la petición (pull request). Destacar los cambios a este nivel de detalle hace que la experiencia de examinación o revisión mejore para cada miembro del equipo y que se den los cambios en pull request de una manera más rápida.
- Revisores por Defecto (4.8): da a los equipos la opción de configurar las acciones predeterminadas que estarán previamente completas en la creación del pull request a partir de cualquier repositorio. Estos examinadores también pueden ser definidos por una fuente y rama de destino, y una vez que esté configurado usted puede agregar o quitar gente de la lista si así lo desea.
BitBucket es parte de la suite Atlassian, orientada a mejorar los procesos y la productividad de tu empresa
