Лекция 142: Зачем нужна автоматизация сборки и тестирования

Когда-то в эпоху "до CI/CD" разработчики руками запускали тесты, двигали файлы между серверами и гадали, почему приложение, которое "работало у меня на локальной машине", выдавало ошибки в продакшене. Времена были непростые. Но, к счастью, программисты не любят отвелкаться на скучную рутину. Поэтому, пораскинув мозгами и технологиями, они придумали автоматизацию сборки и тестирования. Так что теперь мы и другие программисты можем направить наше время и усилия на более важные задачи, вместо того чтобы искать пропавшие ; или пробелы.

Автоматизация сборки и тестирования — это фундаментальные шаги на пути к CI/CD. Но зачем всё это нужно? Давайте разбираться.

Автоматизация сборки

Сборка (build) — это процесс преобразования вашего кода в готовую программу, которую можно запустить. Для Java-приложений это обычно означает превращение исходных файлов .java в .class, а затем в конечный .jar или .war файл.

Проблемы ручной сборки

Если у вас небольшой проект, сборка вручную не такая уж большая проблема. Ну, чаще всего. Но представьте проект с сотнями классов, десятками модулей и рядом зависимостей. Вы каждый раз будете выполнять эти шаги? Это потеря времени! А ошибки… Они будут ждать вас за каждым углом.

Зачем нужна автоматизация сборки?

Автоматизация сборки решает множество проблем:

1. Экономия времени. Вместо того чтобы вручную запускать команды, вы настраиваете процесс один раз, а система всё делает за вас.
2. Повторяемость. Каждая сборка происходит одинаково, минимизируя риск человеческих ошибок.
3. Обработка зависимостей. Инструменты сборки автоматически находят, загружают и подключают необходимые библиотеки.
4. Интеграция с CI/CD пайплайнами. Системы вроде Jenkins, GitLab CI или CircleCI могут автоматически запускать сборку после каждого изменения кода.

Инструменты для автоматизации сборки

Разработчики Java живут как за каменной стеной, имея несколько отличных инструментов. Вы о них уже слышали, и не раз.

• Maven — любимец корпоративного мира, который требует от вас строго соблюдать установленный формат, зато автоматизирует всё: от компиляции до генерации документации.
• Gradle — современная альтернатива Maven, которая предлагает больше гибкости и лучше работает с Kotlin.
• Ant — инструмент старой школы, который всё ещё используется, хотя требует больше конфигурации вручную.

Пример pom.xml файла (Maven), который демонстрирует автоматизацию сборки:

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>awesome-app</artifactId>
    <version>1.0.0</version>
    <packaging>jar</packaging>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.0.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>17</source>
                    <target>17</target>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Этот файл автоматически собирает проект, скачивает зависимости и компилирует код.

Автоматизация тестирования

Тестирование — это как контрольная закупка, только в индустрии ПО. Вы проверяете, всё ли работает так, как задумано, ещё до того, как это увидят пользователи.

В Java мы обычно говорим о трёх основных типах тестов:

1. Юнит-тесты — тестируют отдельные классы или методы.
2. Интеграционные тесты — проверяют, как различные модули работают вместе.
3. End-to-end (E2E) тесты — тестируют приложение целиком, включая взаимодействие с внешними системами (например, базой данных).

Зачем автоматизировать тестирование?

Ну, хотя бы затем, что ручное тестирование — адок ещё тот. Плюс оно медленное. Автотест выполнит за минуту то, что ручной тестировщик будет проверять часами. Кроме того, каждый автотест выполняется одинаково, исключая человеческий фактор. И еще: тесты запускаются часто (например, при каждом коммите), что позволяет оперативно исправлять баги.

Инструменты для автоматизации тестирования

В Java-инфраструктуре есть множество инструментов:

• JUnit — основной инструмент для написания и выполнения тестов.
• Mockito — библиотека для создания моков и заглушек.
• Spring Boot Test — набор инструментов, интегрированных в Spring Boot, для тестирования сервисов и контроллеров.

Пример простого юнит-теста с использованием JUnit:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class CalculatorTest {

    @Test
    void testAddition() {
        Calculator calculator = new Calculator();
        int result = calculator.add(2, 3);
        assertEquals(5, result, "2 + 3 должно быть равно 5");
    }
}

Интеграция автоматических шагов в CI/CD пайплайн

Автоматизация сборки и тестирования отлично вписывается в CI/CD:

1. Каждый коммит вызывает пайплайн. Например, разработчик делает изменения, пушит их в репозиторий, и пайплайн автоматически начинается.
2. Сборка запускается автоматически. Инструменты вроде Jenkins запускают процесс сборки и создают артефакты.
3. Тесты выполняются после сборки. Если проблема найдена, пайплайн останавливается, и разработчик получает уведомление.

Пример .gitlab-ci.yml файла:

stages:
  - build
  - test

build:
  stage: build
  script:
    - mvn clean package

test:
  stage: test
  script:
    - mvn test

Теперь при любом коммите GitLab CI автоматически запустит Maven сборку и тесты.

Заключительный пример: от кода к продакшн

Как это выглядит на практике:

1. Разработчик пишет новый код и пушит его в репозиторий.
2. CI/CD запускает пайплайн, который:
   • Собирает проект с помощью Maven.
   • Выполняет тесты с JUnit.
   • Создаёт артефакт (например, файл .jar).
   • Развёртывает артефакт на тестовую среду.

Если всё прошло успешно, изменения попадают в продакшн.

Переходим к следующей лекции, где мы начнем разбираться с настройкой инструментов CI/CD, чтобы всё это заработало как по маслу.