우리는 프로젝트를 작성하고 있습니다. SpringBoot를 추가하고 CI 프로세스 설정 - "A부터 Z까지 Java 프로젝트"

Java 프로젝트 생성에 관한 시리즈 기사입니다(다른 자료에 대한 링크는 끝에 있습니다). 그 목표는 핵심 기술을 분석하는 것이고, 그 결과는 텔레그램 봇을 작성하는 것입니다. 안녕하세요, 독자 여러분. 이전 부분 에서 설명한 대로 계획대로 진행하겠습니다. 우리는 이미 프로젝트를 만들었고 이제 코드로 채울 차례입니다. 이제 모든 이슈가 별도의 커밋으로 추가됩니다. 여기서 필요한 모든 것을 설명하겠습니다. 제가 놓친 부분이나 명확하게 설명하지 못한 부분이 있으면 댓글로 질문해 주시면 답변해 드리겠습니다.

JRTB-0M을 쓴다

이 작업에서는 향후 작업을 위해 빈 SpringBoot 프레임워크를 추가해야 합니다. SpringBoot + Flyway에 대한 기사 에서 했던 것과 같은 방식으로 이 작업을 수행할 것입니다 . 프로젝트를 다운로드하고 IDEA에서 열고 JRTB-0 이라는 새 분기를 만듭니다 . 여기 아이디어를 통해 이를 수행하는 방법을 설명했습니다 . 이렇게 하면 향후 작업을 더 쉽게 추적할 수 있습니다. 더 이상 마스터 브랜치 가 없다는 것을 이미 알고 계셨나요 ? 이제는 neutral- main 이라고 합니다 . 그래서 우리는 그것에 익숙해집니다. 하지만 솔직히 말해서 언제든지 이름을 다시 master로 바꿀 수 있습니다. Spring Initializr 로 이동하여 봇을 위한 SpringBoot 프레임워크를 생성합니다. 현재 제공되는 부트 스프린트의 최신 버전은 2.3.7입니다. 다음 설정에 대해 별도로 설명하겠습니다.

• 프로젝트: Maven 프로젝트 - 우리는 이미 여기 와 여기에서 Maven에 대해 논의했습니다 . 따라서 이전 기사에서 공개하지 않은 내용에 대해서만 추가로 설명하겠습니다. 물론 그러한 "흰 반점"이 있는 경우)
• 언어: Java - 여기에서는 모든 것이 명확합니다. 원하는 경우 이 문제를 Kotlin으로 다시 작성할 수 있습니다. 방금 Kotlin in Action 책을 구입했습니다. 우리는 함께 Kotlin을 배울 것입니다))
• Spring Boot: 2.3.7 - 문제를 제거하기 위해 제공되는 가장 작은 버전을 사용합니다. 이것은 이미 완전히 최신 버전의 부팅입니다.

프로젝트 메타데이터:

• 그룹: com.github.javarushcommunity - 여기서는 저장소 그룹이 호스팅되는 도메인을 선택합니다.
• 아티팩트: javarush-telegrambot - 프로젝트에 대한 최대 설명입니다.
• 이름: Javarush TelegramBot - 여기에 전체 내용을 작성하겠습니다.
• 설명: 커뮤니티에서 커뮤니티로의 Javarush용 텔레그램 봇 - 프로젝트에 대한 자세한 설명은 다음과 같습니다.
• 패키지 이름: com.github.javarushcommunity.jrtb - 여기에서는 이미 프로젝트 이름의 약어를 사용할 수 있습니다. 이제 프로젝트는 이 패키지로 시작됩니다. 왜 그렇게 많은가요? 따라서 클래스 경로에 다른 프로젝트를 추가하면 해당 프로젝트는 다른 패키지에 있게 됩니다. 각각 고유한 방식으로. 이는 OOP 원칙을 유지하는 데 중요합니다.
• 포장: Jar 가 표준임)
• Java: 11 - 우리는 한 발 앞서 나갈 것입니다. 여덟 번째 Java 이후에는 혁신을 사용하지 않을 것이라고 생각하지만 그대로 두십시오. 그는 음식을 요구하지 않습니다.... 이 결정은 미래에 우리에게 작은 부활절 달걀을 줄 것입니다)

지금은 종속성을 추가하지 않습니다. 이 작업에는 이것이 필요하지 않습니다. 이 모든 항목을 채우면 다음과 같은 결과가 나옵니다( 생성된 프로젝트에 대한 링크는 다음과 같습니다). 항목을 입력한 후 GENERATE(생성)를 클릭하고 아카이브의 모든 내부 항목을 프로젝트에 추가합니다. 프로젝트에 파일을 추가합니다. 결과적으로 우리는 신청서를 받았습니다. 완전히 조립되었는지 확인하려면 터미널로 이동하여 다음을 작성하십시오. $ mvn clean package 여기와 동일하다면 모든 것이 정상입니다. 프로젝트가 조립되었으며 jarnik이 이미 대상 폴더에 준비되어 있습니다. 이제 설명 내의 작업이 준비되었습니다. 간단하죠? 따라서 우리는 커밋하고 브랜치에 푸시합니다. 커밋 설명 시작 부분에 작업 이름을 추가하여 나중에 작업이 수행된 작업 프레임워크 내에서 명확해질 수 있도록 합니다. Commit and Push를 클릭합니다 . 다시 한 번 로컬 저장소에서 원격 저장소로 정확히 푸시하려는 항목을 검토하고 확인한 다음 모든 것이 정상인지 확인하고 Push를 클릭합니다 . 우리의 다음 단계는 무엇입니까? 모든 규칙( 이 문서 의 GitHub 흐름에 대한 부분에서 읽을 수 있음)에 따라 메인 브랜치에 대한 풀 요청을 생성하고 팀의 누군가가 코드를 검토할 때까지 기다려야 합니다. 제가 혼자이기 때문에 공식적으로 Pull Request를 생성하고 모든 것을 다시 검토하겠습니다. 저장소 페이지로 이동했는데 Github는 이미 추가 사항이 있다는 것을 알고 끌어오기 요청을 생성하라는 제안을 했습니다. 애국자에게는 장애물이 없습니다(c). 제안한 대로 생성합니다. 작업 중인 작업과 동일한 레이블, 프로젝트를 설정하고 설명을 입력합니다. Create pull request를 클릭합니다 .

CI 프로세스 설정

생성된 끌어오기 요청으로 이동합니다. 아래에서는 지속적인 통합 (이하 CI) 이 구성되어 있지 않음을 알 수 있습니다 . 음, 구성되지 않았습니다. 그래서 어쩌죠? CI가 왜 필요한가요? CI란 도대체 무엇일까? 이것은 현재 우리가 관심을 가져야 할 질문 목록입니다. 일반적으로 CI는 코드를 공통 코드 베이스로 병합하고 그 전에 프로젝트 빌드를 실행하는 지속적인 프로세스입니다. 소위 빌드(영어 빌드에서 유래). 프로젝트를 빌드할 때마다 프로젝트가 컴파일되었는지, 모든 테스트가 성공적으로 통과했는지 확인하고, 프로젝트를 빌드한 후 이 특정 빌드에서 실행되는 CI에 테스터의 자동 테스트를 추가할 수 있습니다. 이러한 방식으로 우리는 새로운 변경 사항이 예상대로 작동하고 이전 기능을 손상시키지 않는다는 확신을 갖게 되었습니다. CI도 코드베이스 업데이트 후 자동으로 시작되기 때문에 좋습니다. 즉, 변경 사항을 브랜치에 적용하고 어셈블리, 테스트, 자동 테스트 및 기타 단계 등의 프로세스가 시작되었습니다. 이러한 단계 중 하나라도 실패하면 빌드가 손상된 것으로 간주되어 기본 분기에 병합될 수 없습니다. 이것이 바로 지금 우리가 할 일입니다. 푸시 후에 코드를 실행할 GitHub Actions를 추가하겠습니다. GitHub Actions는 GitHub Flow에 완벽하게 들어맞으므로 이를 사용하여 작업을 자동화할 것입니다. 이 도구는 매우 강력하고 크지만 지금은 빌드를 실행하고 필요에 따라 어셈블되었는지 확인하는 데만 사용하겠습니다. 이를 활성화하려면 저장소 페이지에서 작업 버튼을 찾아 따르십시오. 필요한 지속적인 통합 워크플로우를 찾으십시오. 이 워크플로우 설정을 클릭하십시오. 다음으로 해당 템플릿을 사용하라는 제안을 받았습니다. 우리는 완전히 동의합니다. 모든 것을 조금 명확히 하겠습니다.

# 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이 두 가지 경우에 호출됨을 나타냅니다.

1. 메인 브랜치에 푸시가 이루어질 때.
2. 풀 리퀘스트가 메인 브랜치에 생성될 때.

작업 섹션에서는 수행될 단계를 설명합니다. 우리에게는 빌드라는 한 단계만 남았습니다. 이는 우리 프로젝트가 mvn -B package --file pom.xml 명령을 사용하여 Ubuntu에서 시작된다는 것을 보여줍니다 . 이것이 바로 우리가 현지에서 한 일입니다. 여기서 뭔가를 바꾸고 싶다면, 제발. 이 템플릿을 사용하겠습니다. 이 템플릿이면 충분합니다. 커밋 시작을 클릭하고 새 분기 생성을 선택하여 프로세스를 구성한 다음 새 파일 제안을 선택합니다 . 하지만 빌드 프로세스가 떨어졌습니다... 보시다시피 14초 이후 실패 - 빌드입니다. 무슨 일이 있었던 것 같습니다. 어셈블리로 넘어가 세부 사항을 살펴보겠습니다. 그런 기억을 찾을 수 없다고 합니다. 왜? 아아아, 정확해요, 정확해요! 마스터 브랜치에서 변경 사항을 생성했지만 아직 작업이 완료되지 않았기 때문입니다. 그래서 그는 메모리를 찾지 못했습니다... 따라서 이제 다음을 수행합니다. 이 데이터를 마스터에 병합한 다음 메인 브랜치를 JRTB-0에 병합하면 모든 것이 잘 될 것입니다. Github 작업이 변경된 풀 요청에서 Merge pull request를 클릭 하고 병합 확인을 반복합니다 . 다음으로 Github에서는 우리가 작업한 브랜치를 삭제하라는 메시지를 표시합니다. 우리는 거부하거나 삭제하지 않습니다. 다음으로 SpringBoot의 풀 요청에서 웹 사이트의 메인 브랜치에서 변경 사항을 가져오는 방법을 찾지 못했기 때문에 IDEA를 통해 수동으로 수행하겠습니다.

1단계: 마스터 브랜치를 로컬 저장소로 업데이트합니다.

아이디어는 마스터 브랜치로 이동하여 ctrl + t를 누르고 마스터 브랜치를 업데이트하는 것입니다.

2단계: 마스터 브랜치의 변경 사항을 JRTB-0 브랜치에 병합합니다.

JRTB-0으로 이동하여 기본 항목을 병합해 보겠습니다.

3단계: 변경 사항을 푸시합니다.

Ctrl + Shift + k를 누르고 푸시를 확인합니다. 이제 빌드가 통과되기를 기다리고 있으며 녹색이 될 것입니다!)) 그러나 다시 빨간색입니다. 그것은 무엇입니까? 작업 로그로 이동하여 Java 버전이 동기화되지 않았음을 확인합니다. GitHubActions에서는 8이지만 11을 사용합니다. 이제 작업을 수정하거나 버전을 8번째로 낮추는 두 가지 옵션이 있습니다. 제 생각에는 첫 번째 옵션이 더 좋고 더 정확합니다. 우리는 별도의 커밋으로 변경하고 있습니다. Java 8이 아닌 Java 11에서 작업할 것입니다. 그 후 마침내 모든 것이 잘 풀렸고 프로젝트에 대한 CI 프로세스를 설정할 수 있었습니다. 이런 것들은 초기 단계에서 설정해야 나중에 걱정할 필요가 없습니다. 이제 빌드가 통과되었으며 걱정 없이 병합할 수 있음을 확인할 수 있습니다.

저장소의 브랜치를 사용한 작업 설정

브랜치 작업 시 저장소에서 이러한 항목을 규칙으로 구성할 수도 있습니다. 메인 브랜치를 직접 push할 수 없고 pull request를 통해서만 push할 수 있도록 만들고 싶고, 빌드가 실패하면(즉, GitHub Actions가 20초에 실패한 경우에는 pull request 병합이 불가능하도록 만들고 싶습니다.) 몇 단계). 이렇게 하려면 설정 버튼을 찾아 브랜치를 선택하세요 . 현재 브랜치에 대한 규칙이 없으므로 규칙 추가 버튼을 통해 새 규칙을 추가해 보겠습니다 . 여기에는 많은 설정이 있으며 누구나 자신에게 맞는 작업을 수행할 수 있습니다. 필요합니다. 병합 전 끌어오기 요청에서 빌드가 성공적으로 통과하려면 병합 전 상태 확인 통과 필요 확인란을 추가하고 필요한 상태인 빌드를 선택하세요. 지금은 이것으로 충분합니다. 그런 다음 이 스티어링 휠을 업데이트하고 원하는 다른 항목을 확인할 수 있습니다. 생성을 클릭하여 이 스티어링 휠을 생성합니다. 다음으로, 끌어오기 요청으로 다시 이동하면 이제 확인이 필수로 표시되어 있는 것을 볼 수 있습니다. 모든 작업 상태를 표시하는 프로젝트 페이지를 확인해 보겠습니다. 작업 중인 작업을 즉시 확인할 수 있습니다. 게다가 작업은 이미 완료되어 코드리뷰 상태입니다.

JRTB-0 폐쇄

이제 끌어오기 요청을 준비하고 이에 대한 CI를 만들었으므로 마지막 단계를 완료해야 합니다. 작업을 닫고 올바른 상태로 이동하고 보드에서 프로젝트의 변경 사항을 살펴보세요. 풀 요청을 마스터 에 병합할 준비가 되었습니다. 풀 요청에서 풀 요청 병합 버튼을 클릭합니다 . 병합이 성공적으로 완료되면 이를 삭제할 수 있으며 일반적으로 그렇게 합니다. 분기/커밋 간의 변경 사항을 더 쉽게 볼 수 있도록 하기 위해 이 작업을 수행하지 않습니다. 풀 요청이 병합되자마자 프로젝트 보드에서 자동으로 완료 상태가 됩니다. 마지막 단계는 풀 요청이 포함된 링크로 이슈(이슈)를 닫는 것입니다. 이 문제는 자동으로 완료 상태로 전환됩니다. 판자. 시작이 이루어졌고 첫 번째 작업이 완료되었습니다!

결론

이미 작업과 코드 작성을 시작한 것처럼 보이지만 여전히 설정이 필요합니다. 예, 시간이 걸리지만 프로젝트가 더 커지고 복잡해지면 100배의 성과를 거둘 것이며 한 번의 커밋으로 모든 것을 중단하지 않을 것이라는 보장이 필요합니다. 이 모든 일이 발생하는 풀 요청은 여기에서 확인할 수 있습니다 . 아마도 당신이 읽을 때 그것은 이미 닫혀 있을 것입니다. 무섭지 않습니다. 필요한 모든 정보가 링크를 통해 저장됩니다. 읽어주신 모든 분들께 감사드립니다. 곧 뵙겠습니다. 뿐만 아니라!

시리즈의 모든 자료 목록은 이 기사의 시작 부분에 있습니다.