Тележка с Фруктами (Серия из 4 частей)
Истории нарезаны, цели поставлены, теперь пришло время раскрутить тележку.
Настройка и запуск проекта всегда были для меня неудобными. Вы запускаете проект только один раз в течение его продолжительности, поэтому все шаги, которые вам нужно предпринять, чтобы подготовить его к кодированию, не находятся ни в моей мышечной памяти, ни в памяти моего мозга. В конце концов, я не постоянно начинаю новые проекты.
Но начинать мы должны. Итак, в начале, вот что мы сделали:
Загрузил проект Gradle с помощью https://start.spring.io/ Мы добавили зависимости JPA, Devtools и Postgres, которые вы можете найти на сайте. Мы будем использовать MyBatis для выполнения миграций, но не в качестве картографа; это будет обрабатываться “под капотом” библиотекой репозитория JPA.
Инициировал репозиторий Git (удаленный и локальный) для Fruit Cart и выполнил нашу первую фиксацию исходной кодовой базы.
Установил и запустил сервер Postgres. Следуйте этим инструкциям, чтобы создать новую базу данных “корзина фруктов” с суперпользователем “корзина фруктов”:
Запустите сервер postgres и настройте базу данных * * проверьте, существует ли суперпользователь корзины фруктов запустите “psql -c ‘\du'” * если пользователь не существует запустите “c” (не нужно устанавливать пароль, по умолчанию используется “postgres”) * * создать базу данных корзина с фруктами запустить “./gradlew initdb” * создайте миграции для таблицы фруктов с идентификатором столбцов, описанием и имя. Выполнить”./gradlew создан b” * чтобы добавить некоторые данные запустите “psql -h локальный хост -U фруктовая карта –пароль -d фруктовая карта
Запустил чистую сборку, чтобы проверить, не было ли каких-либо ошибок (предупреждение о спойлере: были – база данных настроена неправильно).
Создал задачи Gradle для инициализации и создания нашей базы данных на чистой сборке. После того, как мы правильно настроили нашу базу данных и запустили ее на порту 5432, мы были готовы начать наши первые тесты.
Но давайте вернемся на секунду назад. Давайте поговорим о еде на вынос.
Во-первых, миграции должны быть созданы и запущены из командной строки в том же каталоге, в котором находится ваша среда базы данных. Я знал это раньше, но это стоит повторить, потому что я обычно забываю об этом (эй, этот блог тоже для меня ресурс).
Команда: ./mybatis/bin/перенести новое имя миграции
Это должно создать файл (имя которого начинается с метки времени – миграции выполняются в том порядке, в котором они были созданы) в каталоге сценариев. Используйте это для добавления ваших инструкций SQL.
Второй: Если вы правильно к этому относитесь, .gitignore – ваш друг.
Таким образом, есть определенные файлы, которые мы не хотим видеть в нашем удаленном репозитории. Обычно я думаю о .gitignore как об удобном месте для сокрытия секретов, но я думаю, что более практично это позволяет нам скрывать те части нашего проекта, которые специфичны для наших локальных сборок и не нужны для создания нашего проекта в других средах, таких как те, которые отслеживают изменения в нашей рабочей области или сборке.
Мы использовали https://gitignore.io/ для создания правильного файла .gitignore для IntelliJ, нашей ИДЕИ для этого проекта. Это немного излишне: у нас нет Jira или плагина Crashlytics (для нас это чистый уровень IntelliJ CE), но это дает нам хорошее представление о том, что должно быть включено. Поэтому мы просто скопировали и вставили это в наш собственный.gitignore. И все хорошо.
Ну, не так уж много для Джеффа.
Один из файлов .idea – workspace.xml – продолжал убегать из.gitignore. Он попытался бы зафиксировать/протолкнуть свой код, и произошел бы сбой: в его workspace.xml файл, который не был отслежен. Но, конечно, были, и, конечно, это не будет отслеживаться: это файл, который отслеживает его местоположение в IDE и других внутренних структурах, относящихся к его рабочему пространству. По какой-то причине .gitignore не говорил git, что этот файл не следует отслеживать.
Оказывается, если вы уже зафиксировали этот файл и отправили его в удаленное хранилище, он будет преследовать вас. По словам Джеффа, “Это кусок дерьма”.
Решение: Удалите папку .idea (в любом случае она будет автоматически создана IntelliJ), зафиксируйте изменения, затем добавьте.idea/workspace.xml к вашему .gitignore и добавьте/зафиксируйте/подтолкните все это вверх.
tl;dr: если файл уже был зафиксирован в вашем репозитории, он будет автоматически отслеживаться независимо от того, поместили вы его или нет.gitignore
Третий: может потребоваться ручная настройка SQL с вашей базой данных Postgres.
Наша сборка терпела неудачу. Оказывается, наша база данных не создавалась. Так странно, учитывая, что Postgres работал (я думаю, что он всегда на моей машине; это и Докер). Но база данных не создавалась. Его просто там не было.
Оказывается, нам пришлось создать сценарий оболочки, чтобы фактически создать базу данных, и когда мы это сделали, мы создали владельца, корзину фруктов, которой на самом деле не существовало.
Наш сценарий оболочки сделал функцию createdb просто отличной, и мы выполнили задачу в нашей сборке, но база данных фактически завершилась бы сбоем, потому что не было суперпользователя или даже пользователя с правами на запись. По сути, мы не выполнили первые две * инструкции в начале этого поста. Как только мы это сделали, наша тележка с фруктами появилась на свет.
Теперь все это заняло гораздо больше времени, чем мы думали. И это будет нашей постоянной темой: мы делаем скачки, заходим в интернет-червоточины и тратим много времени на изучение. Мы посмотрели на то, как происходит причал, выброшенный причал после многочисленных неудач. Мы провели много времени с workspace.xml . Мы повозились в Постгресе. Становится все лучше. Но трудно даже знать, какие вопросы задавать, когда ты учишься. Трудно даже понять, где искать, когда ты не знаешь того, чего не знаешь.
И в конце концов, вот что это такое: обучение.
Тележка с Фруктами (Серия из 4 частей)
Оригинал: “https://dev.to/sleepycecy/fruit-cart-config-31f6”