Статья из серии о создании Java-проекта (ссылки на другие материалы — в конце). Ее цель — разбор ключевых технологий, итог — написание телеграм-бота.
Приветствую вас, дорогие читатели. Как было описано в предыдущей части, будем идти по плану. Мы уже создали проект и пора его наполнять кодом.
Теперь все issue будут добавляться отдельными коммитами. Все, что будет необходимо, я опишу здесь. Если что-то упущу или опишу недостаточно понятно — спрашивайте в комментариях, постараюсь ответить.
Пишем JRTB-0M
В этой задаче нам нужно добавить пустой SpringBoot каркас для будущей работы. Делать мы это будем так же, как и делали в статье о SpringBoot + Flyway. Качаем проект, открываем его в IDEA и создаем новую ветку с названием JRTB-0. Как это сделать через идею я описывал здесь. Так будет удобнее понятнее для нас в будущем для отслеживания работы. Вы уже знали, что теперь нет master ветки? Теперь она называется нейтрально — main. Поэтому привыкаем. Хотя, по правде сказать, мы всегда можем переименовать ее обратно в мастер. Заходим на Spring Initializr и создаем SpringBoot каркас для нашего бота.На данный момент самая младшая предлагаемая версия спринта бута — 2.3.7, берем ее. Следующие настройки опишу отдельно:- Project: Maven Project — мы уже разобрали мавен здесь и здесь. Поэтому дополнительно буду описывать только то, что не раскрыл в предыдущих статьях. Если такие “белые пятна” будут, конечно)
- Language: Java — здесь все понятно. Будет желание — можем переписать это дело на Kotlin. Я как раз прикупил себе книжонку Kotlin in Action, будем учить котлин вместе))
- Spring Boot: 2.3.7 — берем самую меньшую из предложенных версий, чтобы исключить какие-либо проблемы. Это и так вполне современная версия бута.
- Group: com.github.javarushcommunity — здесь выбираем домен, на котором хостится наша группа репозиториев.
- Artifact: javarush-telegrambot — максимальное описание проекта.
- Name: Javarush TelegramBot — здесь уже полностью напишем.
- Description: Telegram bot for Javarush from community to community — здесь уже более детальное описание проекта.
- Package name: com.github.javarushcommunity.jrtb — здесь уже можно использовать аббревиатуру для имени проекта. Теперь с этого пакета будет начинаться проект. Зачем так много? Для того, чтобы когда мы добавляли в classpath другие проекты, они были в разных пакетах. Каждый в своем уникальном. Это важно, чтобы сохранять ООП принципы.
- Packaging: Jar — это наш стандарт)
- Java: 11 — будем на шаг впереди. Не думаю, что я буду использовать новшества после восьмой джавы, но пусть уже будет. Есть не просит)... это решение подложит нам небольшую пасхалку в будущем)
Настраиваем CI процесс
Заходим в созданный пулл-реквест: внизу видим, что у нас не настроен Continuous Integration (здесь и далее — CI). Ну не настроен, и что? А зачем нам вообще нужен CI? Что вообще такое CI? Вот примерно тот перечень вопросов, который должен волновать нас в этот момент. В общем и целом CI — это непрерывный процесс сливания кода в общую кодовую базу с запуском сборки проекта перед этим. Так называемый билд (от англ build). Каждый раз, когда мы собираем проект, мы удостовериваемся, что проект прошел компиляцию, все его тесты прошли успешно, плюс к CI после сборки проекта еще можно добавить автотесты от тестировщиков, которые запускаются на эту конкретную сборку. Таким образом получится, что мы становимся более уверенные в том, что новые изменения работают так, как мы ожидаем, и не ломают предыдущий функционал. Также CI хорош тем, что он запускается автоматически после обновления кодовой базы. То есть мы запушили в ветку свои изменения и процесс пошел — сборка, тесты, автотесты и другие шаги. Если какой-то из этих шагов провалился, сборка считается битой и не может быть влита основную ветку. Именно это мы сейчас и сделаем: добавим GitHub Actions, который будет запускать наш код после пуша. GitHub Actions прекрасно ложится на наш GitHub Flow, так что будем использовать его для автоматизации работы. Этот инструмент очень мощный и большой, но пока что мы будем использовать его только для прогонки билда и проверки, что он собирается как нужно. Чтобы включить его, найдем на страничке репозитория кнопку Actions и перейдем по ней:Находим необходимый для нас Continuous Integration workflow:Нажимаем Set up this workflow. Далее нам предлагают использовать их шаблон: полностью соглашаемся, лишь несколько уточним все:
# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven
name: Java CI with Maven
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Build with Maven
run: mvn -B package --file pom.xml
Здесь обозначено, что GitHub Action вызывается в двух случаях:- Когда делается пуш в main ветку.
- Когда создается пулл-реквест в main ветку.
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ