IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Blog de Hinault Romaric (.NET Core, ASP.NET Core, Azure, DevOps)

[Actualité] Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket

Note : 2 votes pour une moyenne de 5,00.
5 Commentaires
par
Hinault Romaric
, 29/10/2016 à 20h16 (3482 Affichages)
J’ai reçu il y a de cela quelques jours un message électronique de la part d’Atlassian, la firme responsable du développement de la solution de contrôle de versions Bitbucket, m’informant de l’intégration d’un nouvel outil au sein de leur plateforme.

Nom : 0524.sdt-atlassian.png Affichages : 5495 Taille : 44,6 Ko

Il s’agit de Pipelines. Ce dernier permet d’ajouter avec facilité l’intégration continue dans un projet hébergé sur Bitbucket Cloud. Son activation se fait en quelques étapes seulement. Il suffit de télécharger sur Bitbucket un template du fichier bitbucket-pipelines.yml, l’éditer pour faire correspondre aux besoins de son projet, et ensuite le commiter sur bitbucket.


Par exemple, pour mon projet ASP.NET Core qui dispose d’un projet de test unitaire avec MsTest V2, le contenu du fichier bitbucket-pipelines.yml est le suivant :

Code yml : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# This is a sample build configuration for .NET Core.
# Check our guides at https://confluence.atlassian.com/x/VYk8Lw for more examples.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: microsoft/dotnet:onbuild

pipelines:
  default:
    - step:
        script: # Modify the commands below to build your repository.
          - dotnet restore
          - dotnet build src/SampleApp
          - dotnet test src/SampleApp.Test

Désormais, à chaque modification de mon code, une build automatique de mon projet est lancée et les tests unitaires sont exécutés :

Nom : Capture1.PNG Affichages : 4189 Taille : 19,0 Ko
Nom : Capture2.PNG Affichages : 4085 Taille : 21,4 Ko

Le résultat de la build est également disponible dans la liste des commits. Ce qui permet de rapidement identifier le commit dont l’opération de build a échoué.

Pipelines permet également de mettre en place la livraison continue. Il peut être configuré pour déployer vos applications sur Microsoft Azure, Amazon Web Services, Google Cloud Platform, le gestionnaire de packages npm et bien plus.

Pipelines est simple et pratique pour rapidement ajouter l’intégration continue à un projet hébergé sur Bitbucket. L’exécution de la solution dans le Cloud (toutes les tâches sont exécutées dans les infrastructures d’Atlassian) offre rapidité et haute disponibilité. Cependant, comparé à un serveur d’intégration continue comme TeamCity, il lui manque encore des fonctionnalités.

Pour l’instant, l’outil est gratuit, mais devrait devenir payant à partir de 2017.

Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog Viadeo Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog Twitter Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog Google Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog Facebook Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog Digg Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog Delicious Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog MySpace Envoyer le billet « Pipelines : quand l'intégration et la livraison en continu s'invitent dans Bitbucket » dans le blog Yahoo

Catégories
.NET Core , Intégration continue , Déploiement continu , Bitbucket , Pipelines

Commentaires

  1. Avatar de Songbird
    • |
    • permalink


    On dirait un peu le même outil que travis, l'addon utilisé sur github.
  2. Avatar de yildiz-online
    • |
    • permalink
    C'est assez proche, cependant piplelines permet d'utiliser des images docker customs, ce qui étend beaucoup les possibilités de build.

    Pour ma part je m'en sert pour faire un scan sonarqube, la compilation de fichiers java via maven, de ressources natives (windows(dll) + linux(so) en cross compilation) et enfin de continuous delivery en poussant le binaire produit sur maven central.

    Les ressources natives sont compilée grâce à une image docker custom qui embarque en sus de maven, un cmake, un mingw64 et un outil pour une précompilation afin de générer les metadata sonar pour les sources c/c++.

    Et tout ça, en faisant un simple git push, un très bon outil à mon sens.
  3. Avatar de steel-finger
    • |
    • permalink
    Gitlab permet la même fonctionnalité au niveau des images custom de docker, nous l'utilisons au taf, quelqu'un à testé cette fonctionnalité sur Bitbucket est-ce que la feature est assez mure ?
  4. Avatar de tchize_
    • |
    • permalink
    J'ai jeté un coup d'oeil il y a quelques semaines et je ne suis pas aussi enthousiaste. C'est pas top pour les projets un peu plus costauds en terme de temps de build, à cause de leurs limitations.

    4Gb ram: mon intégration UI tiens juste pas dedans, elle consomme environ 6G, et je n'ai pas encore mis dedans les tests impliquant la mise en cluster, ce qui nécessitera aà minima 2G de plus pour une vm supplémentaire
    1 seule image docker: j'ai un scenario qui tourne sur jenkins avec gradle qui lance 4 images docker en composite. Pour citer une certaine aventure audio "Ca passe pas... Ca passe pas... Ca passe pas...."
    2h d'exécution: mon plus gros run (test d'intégration) utilise "à peu près" 1h, sur une grosse machine, donc je suppose qu'en environnement partagé je vais exploser ça. Sachant que là on test une 20aine de scénarios, on s'attends plutot à quelques centaines à l'arrivée. A environ 2 minute le scénario de test, à vos calculettes.
    500 minutes / user / mois: là c'est de la foutaise. À 30 minutes de build et de tests divers par commit poussé quand tout va bien (et je compte a nouveau pas encore les tests UI), en gros j'ai droit à un commit tous les 2 jours pour chaque dev. Ca va un peu niquer les perfs de l'équipe.

    Bon après, si ils lèvent les limites en version payante, ça pourra le faire. La tarification du temps CPU a l'air potable (0.01$ / minute). Mais 4G de ram et 2 heures max... Ils doivent avoir la mémoire courte chez Atlassian
  5. Avatar de Hinault Romaric
    • |
    • permalink
    Citation Envoyé par tchize_
    Bon après, si ils lèvent les limites en version payante, ça pourra le faire. La tarification du temps CPU a l'air potable (0.01$ / minute). Mais 4G de ram et 2 heures max... Ils doivent avoir la mémoire courte chez Atlassian
    Je crois que les nombreuses limitations sont dues au fait que le service est encore gratuit pour le moment. Ils fixent des verrous pour ne pas se faire bombarder par des lots d’opérations de builds costaux.

    Je pense qu'à terme, ils devront baisser ces barrières lorsque le service sera payant. J'ai pas idée du système de tarification qui sera appliqué, mais j’imagine qu'il sera basé sur le temps de build et l'utilisation des ressources comme la plus part des services Cloud.

    De plus, maintenir les limitations enlève tout l'attrait du service. Parce que, justement, un tel service à pour objectif de réduire l'investissement nécessaire pour la mise en place de sa propre infrastructure. On verra bien dans quelques mois...