📆 À remettre pour le 2 avril 2021 à 22h
- Utiliser des outils de planification et de gestion efficacement et de façon organisée
- Écrire des récits utilisateurs afin d'énoncer des ajouts de features
- Ajouter des nouvelles fonctionnalités à partir d'un énoncé
- Configurer un déploiement continue de A à Z
Avant d'entamer la programmation, nous vous demandons de lire attentivement les exigences du tp. Nous vous demandons ensuite de planifier vos tâches de développement logiciel avec Github.
- 📜 Créez un milestone pour la remise du tp. Insérez une capture d'écran afin de montrer les informations du milestone ainsi que les issues qu'il contient. Assurez-vous que toutes les issues soient présentes.
- 📜 Créez des issues afin de suivre votre progrès et de vous séparer la tâche.
⚠️ Attention Ce n'est pas nécéssairement 1 issue pour 1 feature. Assurez-vous également d'y remplir l'ensemble des parties tel que vu en laboratoire (l'issue doit au moins être en cours). Insérez une capture d'écran par issue (MAX 3). - 📜 Créez des PRs afin de suivre les changements effectués ou en attente. Assurez-vous également d'y remplir l'ensemble des parties tel que vu en laboratoire. Insérez une capture d'écran par PRs une fois résolue (MAX 3). Vous n'avez pas à scroller afin de montrer le contenu des activités et commentaires.
- 📜 Créez un Github Project contenant vos issues. Insérez une capture d'écran montrant le tableau résultant. Elle peut être effectuée au début comme à la fin de votre progrès. Nous devons au moins y voir les colonnes ainsi que quelques issues. Une seule capture suffit (pas besoin de scroller).
📜 Écrivez, dans votre fichier tp3.md, 8 récits utilisateurs de nouvelles features ou améliorations que vous aimeriez implémenter dans votre projet. Assurez-vous de respecter les points suivants:
- Niveau de complexité adéquat (faisable tout en demandant un certain effort)
- Respect des critères INVEST
- Présence de critères/conditions de succès (tests)
Également, évitez :
- de suivre le format des features dans les énoncés (ce ne sont pas des récits utilisateurs)
- d'indiquer un pointage
- d'implémenter ces features (réservé pour le TP4)
Pour cette partie, vous devez développer les features et refactors demandés. Les formats de requêtes et réponses utilisent la notation typée de Typescript. On s'attend à une réponse dans le format JSON pour l'ensemble des appels à l'API. Des tests automatisés vérifieront les bons retours de votre API. Nous corrigerons également la clarté (clean code), le contenu, l'organisation et l'uniformisation du code.
De plus, vous devez implémenter les mêmes types de tests que pour le TP2 ainsi que respecter les retours d'exceptions demandés.
Votre application étant maintenant entièrement fonctionnelle, il est temps de la déployer sur les Internets! Par contre, plusieurs étapes préliminaires sont requises. Ne vous découragez pas si des bugs persistent, c'est une partie qui peut être difficile!
Bien évidement, on ne demande qu'un seul pipeline de déploiement par équipe.
Vous devez créer un pipeline de déploiement sur Heroku comprenant les 2 environnements suivants:
staging: déployé de façon automatique par le CIproduction: déployé (promoted) manuellement par vous
Vous devrez donc créer 2 applications Heroku afin de pouvoir ensuite les associer à un environnement de pipeline. Les urls peuvent être générés aléatoirement (donc pas nécéssairement reliées au terme e-baie ou glo2003).
tp3.md, insérez une capture d'écran de votre pipeline Heroku. Vous pouvez brouiller ou cacher les adresses courriels si vous voulez.
Avant de pouvoir déployer sur Heroku, quelques étapes de configuration sont nécessaires. Ces dernières sont bien décrites sur le Heroku Dev Center.
Votre application doit être déployée sur Heroku de façon automatique lorsque le code est intégré à la branche de base (main). Ainsi, vous devrez créer un nouveau workflow avec au moins les jobs suivantes:
test: exécute les tests de la même façon que dans votre premier workflow.deploy: déploie l'application sur l'environnementstagingde votre pipeline d'Heroku.- Doit être effectué seulement après la/les job(s) de test.
- Doit effectuer un health check après le déploiement (doit échouer si
/healthne retourne pas200 OK) - Doit rollback (retourner à la version antérieure) si le healthcheck échoue
- Certains Github Actions permettent d'automatiser ces commandes
Vous devriez donc avoir les 2 workflows suivants:
test,CIoubuild: exécute les tests aupushsur toutes les branches, excepté la branchemain.deploy: exécute les tests, puis ensuite le déploiement aupushsur la branchemainseulement.
Assurez-vous de créer un fichier config/heroku_urls.json avec la structure suivantes (sans les chevrons):
{
"staging": "<url vers l'app en staging>",
"production": "<url vers l'app en production>"
}