Intégration continue avec Circleci et Amazon

Dans ma nouvelle équipe, on utilise les services d'hébergement d'Amazon et l'outil d'intégration continue CircleCI. J'ai donc du adapter les différents projets que j'ai architecturé pour les plier à ces exigences. Cela n'a pas été une mince affaire, mais finalement, non seulement ça s'est fait assez rapidement, mais surtout, ça marche du feu de dieu !

Infrastructure

Les applications consistent en des SPA Aurelia tapant une API en CORS. L'une des deux apps a son propre backend en nodejs.

Les clients javascript sont donc hébergés sur Cloudfront/S3. Une tâche a été rajouté au projet pour être lancée avec aurelia-cli qui va créer un nouveau dossier dans le bucket S3, y uploader les fichiers, puis modifier la conf de cloudfront pour faire pointer le root sur ce nouveau dossier et invalider le cache. Cela permet de faire facilement un rollback en cas de problème. Seul soucis : la mise à jour effective prend beaucoup de temps car Amazon prend entre 5 et 10mn à redémarrer le service et à invalider le cache après une mise à jour. Mais gros avantage : ça sert à toute vitesse ! Et on peut créer autant de configuration Cloudfront que d'environnements nécéssaire, en l'occurence une prod et un staging.

Le backend est servi par ElasticBeanstalk. Là aussi, c'est très facile une fois que tout est correctement configuré : on déploie très simplement avec le cli fourni par Amazon. On peut ici aussi facilement cibler l'environnement de son choix : prod et staging.

Intégration continue

CircleCI est un outil intégré avec Github gratuit tant qu'on reste dans des limites très facilement supportable : une build à la fois. Il permet de lancer la construction d'un projet et de lancer ses tests, récupérer éventuellement des fichiers comme le rapport de couverture de code, puis finalement déployer. Tout se configure grâce à un fichier circle.yml dans lequel on décrira la liste des tâches à effectuer, les commandes à lancer avant ou après l'installation, les tests, le déploiement, etc. Et surtout, on peut définir dans quel environnement déployer selon la nature de la construction, par exemple, s'il s'agit de la branche master, on déploie sur staging, mais s'il s'agit d'un tag, on déploie sur la prod.
On en oublie complètement la tâche lourdingue du déploiment : dès qu'une pull request est fusionnée dans master, elle est en staging quelques minutes après et quand on veut envoyer en prod, on se contente de pousser un nouveau tag.

Exemple de configuration circle.yml

machine:
  node:
    version: stable
dependencies:
  pre:
    - npm install -g aurelia-cli
deployment:
  production:
    tag: /.*/
    commands:
      - au i18n load
      - au deploy --env prod
  staging:
    branch: master
    commands:
      - au i18n load
      - au deploy --env stage

Hadrien

Hi, I'm a french Web Lead Developer, Front End Architect from Toulouse, France. I've worked for 7 years for Overblog then 2 years with AngularJS. Now, I'm a great fan of Aurelia.io.

Toulouse, France https://hadrien.eu