Alors que GitLab 12.0.3 est publié, il est temps de faire le tour de la version open-source de GitLab. Avec cette version 12, GitLab fait un pas de plus vers sa promesse : « une seule application pour gérer l’intégralité du cycle de vie d’une application en mode DevOps ».
Cette version est marquée par de nombreux ajouts afin d'assurer la sécurité des applications, notamment dans les versions payantes.
Pour nos amis Dev
Commençons par les fonctionnalités qui vont faciliter la vie des développeurs.
Vous pouvez déployer JupyterHub dans votre Kubernetes grâce à l’intégration GitLab. L’extension git de votre JupyterLab sera alors automatiquement connectée avec GitLab. Vous pourrez gérer les sources de vos carnets de notes hébergés dans GitLab directement depuis Jupyter.
Vous pouvez paramétrer les emails de notification en fonction des groupes, pour mettre votre email professionnel sur vos projets d’entreprise et votre email personnel pour des groupes plus personnels, par exemple.
Ajouter un agrégat K8S sur GitLab demande de renseigner de nombreuses informations, ce qui peut être sujet d’erreurs. L’intégration de Kubernetes valide maintenant l’accès à l’API K8S. Elle vous assure de la validité de votre jeton d’accès et des certificats. Elle affiche une erreur si cela n’est pas le cas.
Vous n’avez plus besoin d’installer Knative via GitLab pour profiter de la fonctionnalité GitLab Serverless. Vous pouvez maintenant connecter un agrégat Kube qui a déjà Knative d’installé.
Le format AsciiDoc peut être inclus depuis un fichier. On évite la duplication suivant la philosophie DRY. La directive (include::example.adoc[]) supporte un fichier sur la même branche ou sur un tag spécifique.
La collaboration
GitLab est aussi un outil de collaboration entre les membres des diverses équipes IT. Cette version apporte donc de nouvelles fonctionnalités dédiées à la coopération :
- Si un lien Zoom meeting est ajouté dans la description d’un ticket alors un bouton est affiché directement sous le nom du ticket. Espérons que cette fonctionnalité puisse être configurable à l’avenir, car chez Lydra nous utilisons plutôt l’outil libre Jitsi.
- GitLab a aussi amélioré la présentation des discussions sur les tickets et les demandes de fusion (Merge Request ou MR) pour rendre la compréhension de la conversation plus fluide.
- Côté API, on peut maintenant obtenir la progression d’un ticket si celui-ci contient une liste de tâches.
La CI
L’intégration continue n’est bien sûr pas en reste :
- Dans GitLab 12 la variable GIT_DEPTH peut être définie directement au niveau du projet. Pour tous les nouveaux projets, elle est à 50 par défaut. Cette variable permet de cloner un projet sans récupérer tout l’historique. Cela permet donc d’accélérer les jobs de la CI.
- Un développeur peut maintenant effacer un tag du registre de conteneur directement depuis l’API.
- Les utilisateurs ont maintenant la possibilité de ne recevoir de notification que sur la branche par défaut du projet, comme master par exemple.
- Les variables sont transmises aux jobs dépendants et déclenchés par le job courant.
- DRY encore, le mot-clé extends peut maintenant être appelé de multiple fois dans le même job de votre fichier .gitlab-ci.yml.
- Les logs des jobs ont été améliorés, on peut maintenant réduire ou étendre les étapes du job.
Puisque nous avons le nez dans la CI, parlons un peu des évolutions sur le runner. Outre la version 12 du runner, nous avons maintenant la possibilité d’être notifiés quand notre quota de CI sur GitLab.com est atteint. Avez-vous pensé à lancer un runner de votre CI sur votre propre station de travail ?
Les autres améliorations
GitLab propose de la visualisation des métriques. Maintenant, on peut accéder directement au tableau de bord de notre solution de supervision externe en un bouton.
Comme à son habitude, GitLab apporte aussi des améliorations à son produit :
- Omnibus, le logiciel d’installation de GitLab inclut maintenant Mattermost 5.11, une alternative open-source à Slack.
- Les log sont en JSON par défaut.
- Grafana et l’authentification Oauth sont activés par défaut.
- Une meilleure gestion des métriques qui sont récupérées directement par ruby.
- De meilleures performances sur : la page epics, ElasticSearch, le rendu Markdown des messages de commit, les pushs, le temps de chargement des tickets ou des demandes de fusion avec de longues descriptions, les graphiques de supervision, et bien d’autres.
- La déduplication des objets Git fait son apparition en beta. Pour contribuer à un projet, il est facile de le forker, cela crée des données en doublon sur les serveurs et consomme inutilement du stockage. Pour les projets populaires, cela peut représenter des milliers de copies. L’administrateur peut maintenant activer la fonctionnalité object_pools. Ainsi, quand un fork est créé, GitLab pourra réduire l’espace utilisé par le fork. Cette fonctionnalité nécessite que vous activiez le stockage hashé sur votre instance. L’autre avantage est que cela accélère le temps de fork d’un projet.
Comme d’habitude dans cet article, je me suis concentré sur les fonctionnalités accessibles à tous dans les versions libres et open-source.
Il y a encore beaucoup de fonctionnalités dans cette version 12. Pour les découvrir, je vous renvoie vers l’article de GitLab sur cette release.
Cette version majeure nous offre un cadre de travail encore jamais atteint.
Tu cherches une instance GitLab hébergée en France ? Rejoins la bêta de Froggit.
Venez nous parler de votre expérience avec GitLab, ou autre, dans la communauté des Compagnons du DevOps.
Photo by Jeremy Bishop on Unsplash
