Intégration GitHub, déploiement automatique et applications de révision

Nous sommes très heureux de publier aujourd'hui notre intégration GitHub approfondie, dévoilant de nouvelles capacités d'autodéploiement lorsque le code est hébergé dans un dépôt GitHub, déployant directement à partir d'une branche GitHub, avec construction et déploiement automatiques des Pull Requests, et bien plus encore.

Chez Scalingo, notre mission est de faciliter la vie des développeurs. Beaucoup d'entre eux utilisent GitHub comme plateforme d'hébergement de code source. Heureusement, GitHub possède des capacités d'interopérabilité particulièrement bonnes que nous avons utilisées pour offrir un flux de travail puissant et bien intégré basé sur GitHub.

Le flux GitHub

Comme la plupart des équipes de développeurs sur GitHub, nous suivons le flux GitHub pour intégrer de nouvelles lignes de code dans notre code source. Ce flux de travail suit ces règles :

• Tout ce qui se trouve dans la branche master est toujours déployable

• Créez une nouvelle branche basée sur master pour chaque nouvelle fonctionnalité ou correction

• Engagez vos modifications sur cette nouvelle branche et poussez-les vers le dépôt GitHub

• Lorsque vous avez besoin de retours ou d'aide ou que vous pensez que la branche est prête à être fusionnée, ouvrez une pull request

• Une fois que quelqu'un d'autre a examiné et approuvé le patch, vous pouvez le fusionner dans master

• Une fois qu'il est fusionné et poussé vers 'master' sur l'origine, vous pouvez et devez déployer immédiatement

Notre intégration GitHub approfondie vise à automatiser ce flux de travail.

L'intégration GitHub

L'intégration GitHub est disponible dans la section 'code' de votre tableau de bord. Elle se compose de deux parties principales : Déploiement automatique et Applications de révision.

Pour activer les fonctionnalités relatives à GitHub sur votre application Scalingo, vous devez la lier à un dépôt GitHub. Vous ne pouvez lier votre application qu'à un dépôt que vous possédez ou qui est détenu par l'une de vos organisations. Remarque : Si c'est un dépôt d'organisation, assurez-vous que vous avez un accès administrateur.

Sous le capot, nous ajouterons un webhook sur votre dépôt qui notifiera la plateforme Scalingo pour chaque événement généré dans le cycle de vie de votre dépôt : comme 'Push', 'Nouvelle pull request', etc.

Déploiement automatique

Une fois votre application liée, vous pouvez activer le 'Déploiement automatique' à partir d'une branche donnée de votre dépôt. Cela signifie que votre application sera fortement liée à la branche sélectionnée, un nouveau déploiement de l'application sera lancé chaque fois que le code de cette branche est mis à jour sur GitHub.

Vous pouvez avoir des outils d'intégration continue associés à votre dépôt tels que Codeship ou TravisCI qui lancent des tâches, des tests ou quoi que ce soit. Nous allons toujours attendre que tous les états GitHub réussissent avant de déployer votre application.

Déploiement manuel

La fonctionnalité de déploiement manuel vous permet de déployer instantanément une branche depuis le dépôt GitHub lié à votre application Scalingo. Cela peut être utile pour déployer rapidement votre application ou dans le cas où vous n'avez pas accès à un ordinateur ayant une installation git appropriée et que vous avez modifié le code directement sur GitHub.

Applications de révision

Les applications de révision sont un outil de collaboration puissant pour discuter de nouvelles fonctionnalités entre les membres de votre organisation.

Disons que vous avez travaillé quelques heures sur une nouvelle fonctionnalité géniale. Il est temps de montrer votre travail au monde et d'ouvrir une nouvelle Pull Request (PR) sur GitHub (même si elle n'est pas complètement terminée). Avec les applications de révision activées sur Scalingo, nous allons créer une nouvelle application, appelée une application de révision avec le code de la nouvelle fonctionnalité. Vous pouvez maintenant facilement partager le résultat de votre travail, pour obtenir une validation, avec toutes les personnes impliquées, même si elles ne sont pas dans le domaine technique.

Peut-être qu'ils vous demanderont de changer quelque chose comme ajouter des tests ou changer la couleur d'un bouton. Vous devez juste pousser votre modification sur la branche impliquée dans la PR pour mettre à jour l'application de révision.

Une fois que tous nos coéquipiers sont satisfaits et que la PR est fermée, nous supprimerons automatiquement l'application de révision. Vous pouvez désactiver ce comportement ou ajouter un délai pour répondre à vos besoins. Ce dernier paramètre signifie que vous pouvez toujours revoir la PR après que votre équipe de développement ait fermé la PR.

Si vous ne voulez pas créer une nouvelle application de révision pour chaque PR, vous pouvez également choisir parmi les PR ouvertes de votre application pour déployer manuellement une application de révision.

Qu'en est-il des addons, des collaborateurs et des variables d'environnement ?

Si vous avez activé les applications de révision, une nouvelle application sera créée chaque fois qu'une nouvelle Pull Request est ouverte dans votre dépôt GitHub. Cette nouvelle application est une application enfant (nous verrons plus tard cette année quelles nouvelles fonctionnalités passionnantes ce lien nous aidera à construire). Cette application enfant aura une copie des addons, des collaborateurs et des variables d'environnement de l'application parente.

La plupart du temps, vous voudrez personnaliser ces 3 éléments. C'est là que les nouveaux hooks postdéploiement et manifestes entrent en jeu. En combinant ces deux puissantes fonctionnalités, vous pouvez exactement adapter la manière dont les applications enfants sont configurées et leur comportement.

Pour donner un exemple rapide, voici un échantillon de scalingo.json qui personnalise la variable d'environnement CANONICAL_HOST_URL pour une application enfant :

{
  "env": {
    "CANONICAL_HOST_URL": {
      "generator": "url"
    }
  }
}

{
  "env": {
    "CANONICAL_HOST_URL": {
      "generator": "url"
    }
  }
}

{
  "env": {
    "CANONICAL_HOST_URL": {
      "generator": "url"
    }
  }
}

{
  "env": {
    "CANONICAL_HOST_URL": {
      "generator": "url"
    }
  }
}

Ici, la valeur de cette variable contiendra l'URL pour atteindre l'application nouvellement déployée. La configuration de scalingo.json a toujours la priorité sur la configuration de l'application parente.

Conclusion et améliorations futures

Beaucoup de gens voient Scalingo comme une plateforme d'hébergement, c'est-à-dire une plateforme hébergeant des services de production. Bien sûr, nous mettons beaucoup d'énergie à faire de Scalingo une qualité de production. Avec cette nouvelle fonctionnalité d'intégration GitHub, Scalingo devient une plateforme encore plus puissante pour les développeurs. Liée à notre récente annonce de plugin Docker, vous pouvez imaginer tous les nouveaux types de flux de travail adaptés à votre organisation d'entreprise, à vos préférences ou à vos contraintes.

Et si vous utilisez Bitbucket ou GitLab, ne vous inquiétez pas, nous pensons déjà à l'intégration avec ces services.