E-PROD-1 : Être prêt à mettre son code en production

L’objectif du laboratoire est de vous familiariser avec la mise en production d’une application et des requis spécifiques à cette étape de la vie de vos applications.

Création d’un compte Heroku

À des fins de simplicité, vous aurez à déployer les applications du laboratoire sur la plateforme Heroku. Un compte de base permet de tester la plateforme et de déployer des applications sur des instances de serveurs appelées Free Dynos.

Veuillez noter que le cours n'a aucune affiliation avec la plateforme Heroku et qu'elle a été choisie seulement parce qu'elle offrait les outils les plus simples pour les besoins du cours.

Cliquez sur le lien suivant pour vous créer un compte: https://signup.heroku.com/.

Déploiement d’une première application

Une fois votre compte créé, suivez les étapes suivantes pour déployer l’application type fournie par Heroku:

Exercice

Code base

Vous vous rappelez de l’application Cart-OO? Celle que vous avez développée il y a déjà plusieurs semaines? Il a été décidé, après plusieurs semaines de délai, de finalement l’envoyer en production! Hourra! Et on vous annonce que l’application sera déployée sur Heroku, que ça vous plaise ou non.

Lors du développement, on vous avait avisé que le port du serveur à utiliser pouvait être une valeur quelconque vers lequel le trafic serait redirigé. Toutefois, la plateforme de déploiement n’avait pas encore été choisie à ce moment-là… Puisque l’application sera maintenant déployée sur Heroku, on vous demande de modifier l’application pour que le port puisse être dynamique et reçu en paramètre.

Veuillez forker le dépôt GitHub suivant: https://github.com/GLO4002UL/officiel-lab-production

Premier défi

Modifiez l’application cart-oo pour qu’on puisse la démarrer sur un numéro de port passé en argument.

Une fois que c’est fait, mettez à jour votre pom.xml afin que Maven crée ce qu’on appelle un JAR-with-dependencies, ou encore, un Uber JAR. Ajoutez le bloc de code suivant dans la section <plugins></plugins>:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-shade-plugin</artifactId>
   <version>3.2.1</version>
   <executions>
       <execution>
           <phase>package</phase>
           <goals>
               <goal>shade</goal>
           </goals>
           <configuration>
               <createDependencyReducedPom>false</createDependencyReducedPom>
               <transformers>
                   <transformer
                       implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                       <mainClass>ca.ulaval.glo4002.cart.CartServer</mainClass>
                   </transformer>
                   <transformer
                       implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
               </transformers>
           </configuration>
       </execution>
   </executions>
</plugin>

Et finalement, le déploiement requiert un fichier Procfile qui décrit comment démarrer votre application. C’est dans ce fichier qu’on pourra également passer nos paramètres dont la fameuse variable $PORT. Voici un exemple de Procfile:

web: java -Dport=$PORT -Dparam1=value1 -Dparam2=value2 -jar target/application-name-1.0.0-SNAPSHOT.jar

Puisque c’est le premier déploiement de l’application, veuillez la déployer en spécifiant le stockage In-Memory.

Une fois que vous avez réussi à déployer l’application correctement, allez vérifier que tout fonctionne via l’interface web: https://epic-austin-420b87.netlify.com/.

C’est à vous de jouer!

Deuxième défi

Maintenant que vous avez trouvé le bug, l’application démarre maintenant correctement. Félicitations!

Toutefois, vous recevez des plaintes de clients qui indiquent qu’ils ne peuvent rien acheter. Votre collègue (qui a apparemment été convoqué par le boss…) vous assure pourtant que la base de données contient des items!

Si vous ne voulez pas finir comme votre (ancien?) collègue, assurez-vous de démarrer l’application en mode démo afin de populer la base de données et de vous assurez que tout roule! Regardez dans l’interface web pour vous assurez que les produits sont bel et bien listés… oops! Que se passe-t-il? Est-ce que les logs vous aide?

Il y a peut-être un peu trop de log en fait. Trop c’est comme pas assez! Prenez le temps de vous familiariser avec logback et sa config (un début de configuration est dans le fichier src/main/resources/logback.xml). Pouvez-vous réduire un peu la verbosité de tout ça? Idéalement, on ne devrait plus voir les logs de jersey… seulement les vraies erreurs! Attention aussi de ne pas juste supprimer tous les logs, les erreurs nous intéressent toujours…

Rappel: Pour populer la base de données, utilisez le mode démo qui s’active avec -Dmode=demo.

Troisième défi: Release Part 1

Puisque l’application est destinée à aller en production, il est généralement considéré comme une bonne pratique de créer une nouvelle version de celle-ci avant son déploiement.

Tout d’abord, mettez à jour votre pom.xml avec les informations de votre dépôt GitHub afin que Maven sache où pousser ses changements de la release. Ajoutez le bloc suivant à l’intérieur de <project></project>:

<scm>
  <connection>scm:git:git@github.com:YOURUSERNAME/officiel-lab-cart-oo.git</connection>
  <developerConnection>scm:git:git@github.com:YOURUSERNAME/officiel-lab-cart-oo.git</developerConnection>
  <url>https://github.com/YOURUSERNAME/officiel-lab-cart-oo</url>
  <tag>HEAD</tag>
</scm>

Vous êtes maintenant prêt à créer votre release! Exécutez la commande suivante:

mvn release:perform -Darguments="-Dmaven.deploy.skip=true"

Une fois la release créée, vous pouvez redéployer votre application.

NOTE: Il est à noter que Heroku ne supporte pas la notion de tag pour le déploiement. Si vous souhaitez déployer un tag, vous aurez à pusher le bon commit sur votre branche de déploiement. Vous trouverez un exemple ci-dessous. Soyez prudent avec les commandes qui suivent, on effectue un force push sur la branche de destination (la branche production dans l’exemple):

mvn release:perform -Darguments="-Dmaven.deploy.skip=true" # Release de la nouvelle version
git push -f origin cart-1.0.0^{}:production # Ceci assume que vous déployez la branche production

Maven Release Plugin

Lors de l’invocation du Maven Release Plugin, Maven exécutera les étapes suivantes:

Quatrième défi: Release Part 2

Si vous avez tentez de déployer l’application et que plus rien ne fonctionne c’est que vous avez oublié de mettre à jour le fichier Procfile avec la nouvelle version de l’application! N’ayez crainte, nous allons résoudre ceci de façon permanente.

Afin d’éviter ce genre de situation où une valeur de version hard-codée est utilisée dans un fichier de configuration, il est possible de configurer maven-shade-plugin pour que le JAR résultant ait toujours le même nom.

Mettez à jour la configuration du plugin maven-shade-plugin dans votre fichier pom.xml avec cette nouvelle ligne:

<plugin>
  ...
  <artifactId>maven-shade-plugin</artifactId>
  ... 
  <configuration>
    ...
    <!-- Défini le nom du JAR final -->
    <finalName>cart-server-app</finalName>
  </configuration>
  ... 
</plugin>

Vous pouvez maintenant mettre à jour votre fichier Procfile pour lancer target/cart-server-app.jar sans spécifier la version.