Une approche consiste à penser d'avant en arrière ou d'arrière en avant. Penser de l'avant vers l'arrière signifie commencer par l'interface utilisateur et une fois celle-ci créée, créer les tiers intermédiaires, et enfin l'arrière-plan.
Le problème avec le démarrage de l'interface utilisateur est que vous ne pouvez pas vraiment vérifier que cela fonctionne sans backend. Mais je crois que c'est un problème Dependency Injection (DI) résout. Vous créez l'interface utilisateur et partout où elle doit appeler la couche suivante dans la pile (par exemple, les API du serveur), vous lui donnez à la place un serveur factice à appeler. Vous pouvez implémenter assez de serveur fictif pour faire passer les histoires BDD pour l'interface utilisateur. Lorsque chaque histoire BDD passe pour l'interface utilisateur, vous pouvez créer la couche suivante dans la pile.
Il devrait être possible de commencer à développer l'interface utilisateur en trouvant un exemple Hello World pour la technologie frontale (AngularJS). Recherchez un exemple Hello World incorporant les deux pièces nécessaires pour les tests: BDD et Dependency Injection. Si vous ne pouvez pas en trouver un, commencez simplement par le Hello World d'AngularJS, lancez-le. Ensuite, en tant que tâche distincte, faites un Hello World pour BDD et j'espère que cela sera apparent après avoir appris à faire fonctionner BDD pour que BDD travaille avec le projet AngularJS. Faites ensuite la même chose pour l'injection de dépendances. Heureusement, cela vous permet d'avoir une interface frontale entièrement implémentée par AngularJS que vous pouvez vérifier avec BDD et l'injection de dépendances.
Ensuite, vous pouvez travailler sur le niveau intermédiaire. Vous pouvez le configurer en tant que projet séparé, indépendant du projet AngularJS, afin que vous n'ayez pas à vous soucier des tracas de combiner le code de deux couches de la pile en un seul projet. Maven devrait être capable de faire cela, mais la documentation pour Maven a tendance à ne pas être aussi facile à utiliser.
Pour développer le niveau intermédiaire, recherchez un exemple Hello World pour développer un serveur API REST fonctionnant sur Google Cloud. Vous n'avez pas besoin de l'avant ou de l'arrière à ce stade. L'avant peut être simulé par les histoires BDD et l'arrière peut être simulé par DI. Une fois que toutes les histoires BDD passent pour la couche intermédiaire, vous pouvez construire le back-end.
Le développement de l'arrière-plan est similaire à la construction de la couche intermédiaire. Recherchez un exemple Hello World pour développer une application de base de données fonctionnant sur Google Cloud. Il est fort probable que la technologie pertinente soit le magasin de données Google utilisant Objectify comme un wrapper orienté Objected. Mais appelons cette couche la couche de service car il devrait exister une couche d'abstraction entre l'API REST et le magasin de données. La complication ici n'est peut-être pas très simple de développer cette couche indépendamment du niveau intermédiaire, mais essayez si possible de le faire. En d'autres termes, créez un projet distinct basé sur un exemple de Google Datastore Hello World. Utilisez BDD pour simuler le niveau intermédiaire. Vous n'aurez peut-être plus besoin de DI parce que vous êtes au bas de la pile, appelez directement le magasin de données. Mais DI peut être utile de toute façon s'il n'est pas possible d'exécuter le magasin de données sur votre machine locale où vous développez. Maintenant que vous avez des histoires BDD fonctionnant sur les trois couches (interface utilisateur, REST API middle-tier, back-end de la couche de service), commencez à le faire fonctionner sur les serveurs de production. Je ne suis pas sûr que ce soit la meilleure approche, car il semble que beaucoup de complications pourraient survenir dans cette dernière étape. Théoriquement, si chaque couche a passé les tests BDD, alors tout devrait bien se fermer. Mais l'intégration de tout cela pourrait ne pas aller aussi bien. Une stratégie pour s'assurer que tout se passe bien est de cartographier chaque couche sur son propre système de production dédié. Si chaque pièce fonctionnait correctement sur une machine de développement, ne devrait-elle pas fonctionner sans problème sur une machine de production? J'espère que quelqu'un d'autre proposera une meilleure approche qui permettra à quelqu'un de passer encore plus de temps sur le codage et de consacrer moins de temps à cette tâche DevOps.