Как настроить Google Cloud для разработки Driven Driven Development (BDD) для веб-приложения с клиентом AngularJS и сервером Java?

Question

Я хочу сделать разработку, управляемую поведением (BDD) в Google Cloud. Я написал свои истории BDD, и похоже, что базовое веб-приложение будет удовлетворять требованиям. Я хотел бы использовать AngularJS для написания клиентского кода и Java для сервера, потому что это то, что я больше всего знаю. Я также немного знаком с Maven.

Как начать работу таким образом, чтобы я мог сосредоточиться на написании кода?

1] Выберите облачную службу Google (двигатель приложения, вычислительный двигатель, контейнерный движок)?

2] Найдите и скопируйте пример Hello World для любой технологии, которая также имеет как и многие другие компоненты, которые я хочу использовать (JBehave для BDD, AngularJS, Java, служба Google Cloud выше)? Но с чего начать, с чего начать, чтобы другие компоненты легко интегрировались?

3] Найти подходящий архетип Maven?

4] Исследуйте Spring.io? Я слышал, что Spring.io пытается упростить разработчикам сосредоточиться на кодировании. Но я ничего не знаю об этом.

Я бы хотел потратить как можно меньше времени на создание проекта, чтобы я мог как можно быстрее начать разработку поведения. То, что я обычно нахожу, случается с таким проектом, я блокирую одно из решений о том, какую технологию использовать, следуйте руководству по началу работы, а затем заходите в кирпичную стену, когда я начинаю интегрировать другие компоненты.

Как начать этот проект, чтобы я мог потратить наименьшее количество времени на аспекты без кодирования, насколько это возможно?

Answer 1

Лично я бы не сосредоточился на том, где выполнить систему. Мой мир, разработка выполняется на локальном компьютере. CI выполняется где-то еще, и конечные артефакты выполняются где-то. Это место должно быть возможно для развертывания с вашей сборки CI, чтобы вы могли убедиться, что он действительно работает до развертывания.

Я хотел бы начать с создания чего-то, что работает локально на моем компьютере, а затем двигаться вперед. Я бы не стал тратить время на поиски архетипа Maven, я бы медленно создал свой проект вручную. Это может звучать как медленный способ сделать это, но это даст мне знания о том, что происходит. Добавленная магия - это волшебство, которое я добавил и, следовательно, не волшебство.

С чего начать? Я предлагаю начать с клонирования https://github.com/cucumber/cucumber-java-skeleton и расширить его с помощью необходимых бизнес-функций. Если вам нужно больше технологий, добавьте его, когда вам это нужно. Не раньше, чем нужно. Мой опыт в том, что мне обычно требуется меньше технических средств, чем можно было себе представить с самого начала. И определенно не инструмент, о котором я мог думать, прежде чем начать проект.

Answer 2

Один из подходов - думать спереди назад или назад. Мышление спереди назад означает запуск с пользовательского интерфейса, и как только он будет создан, создайте средние уровни и, наконец, задний конец.

Проблема с запуском с пользовательским интерфейсом заключается в том, что вы не можете действительно проверить, что он работает без бэкэнд. Но я считаю, что это проблема, вызванная Dependency Injection (DI). Вы создаете пользовательский интерфейс и везде, где ему нужно вызывать следующий уровень в стеке (например, API-интерфейсы сервера), вы вместо этого даете ему макетный сервер для вызова. Вы можете реализовать достаточно макетного сервера, чтобы рассказы BDD передавались для пользовательского интерфейса. Когда каждый рассказ BDD проходит для пользовательского интерфейса, вы можете затем построить следующий слой в стеке.

Должно быть возможно начать с разработки пользовательского интерфейса, найдя пример Hello World для технологии front-end (AngularJS). Ищите пример Hello World, который включает в себя две необходимые части для тестирования: BDD и Injection Dependency. Если вы не можете найти его, просто начните с Hello World, чтобы он работал. Затем, как отдельная задача, сделайте Hello World для BDD, и, надеюсь, это станет очевидным после изучения того, как заставить BDD работать, чтобы BDD работал с проектом AngularJS. Затем сделайте то же самое для Injection Dependency. Надеюсь, это поможет вам полностью интегрировать интерфейс AngularJS, который вы можете проверить с помощью BDD и Injection Dependency Injection.

Тогда вы можете работать на среднем уровне. Вы можете настроить его как отдельный проект, независимо от проекта AngularJS, чтобы не беспокоиться о проблемах сочетания кода из двух слоев стека в один проект. Maven должен уметь это делать, но документация для Maven не так проста в использовании.

Чтобы разработать средний уровень, найдите пример Hello World для разработки сервера API на основе REST, который работает в Google Cloud. В этот момент вам не нужен передний или задний конец. Переднюю часть можно смоделировать в рассказах BDD, а задний конец может быть смоделирован DI. После того, как все истории BDD пройдут для среднего слоя, вы можете создать внешний интерфейс.

Разработка back-end похожа на создание среднего слоя. Найдите пример Hello World для разработки приложения базы данных, которое выполняется в Google Cloud. Скорее всего, соответствующая технология - это хранилище данных Google, использующее Objectify как Objected Oriented wrapper. Но назовем этот слой слоем сервиса, потому что должен существовать слой абстракции между REST API и хранилищем данных. Усложнение здесь может быть не очень простым для разработки этого слоя независимо от среднего уровня, но попытайтесь, если возможно, сделать это. Другими словами, создайте отдельный проект, основанный на примере Google Datastore Hello World. Используйте BDD для имитации среднего уровня. Вам может не понадобиться DI больше, потому что вы находитесь в нижней части стека, просто позвоните в хранилище напрямую. Но DI может быть полезен в любом случае, если невозможно запустить хранилище данных на вашей локальной машине, где вы работаете.

Теперь, когда у вас есть истории BDD, работающие на всех трех уровнях (интерфейсный интерфейс пользователя, средний уровень уровня REST API, back-end сервисного уровня), теперь запустите его работу на рабочих серверах. Я не уверен, что это лучший подход, хотя, похоже, на этом последнем этапе может возникнуть множество осложнений. Теоретически, если каждый уровень прошел тесты BDD, тогда он должен хорошо сочетаться друг с другом. Но интеграция всего этого может пойти не так гладко. Одна из стратегий обеспечения уверенности в том, что она идет гладко, состоит в том, чтобы сопоставить каждый слой с собственной выделенной производственной системой. Если каждая деталь работает плавно на машине разработки, не следует ли ее бесперебойно работать на производственной машине?

Надеюсь, но я надеюсь, что кто-то другой предложит лучший подход, который позволит кому-то потратить еще большую долю времени на кодирование и меньшую долю времени на этот материал DevOps.