Nagsusulat kami ng isang proyekto. Magdagdag ng SpringBoot at mag-set up ng proseso ng CI - "Java project from A to Z"

Isang artikulo mula sa isang serye tungkol sa paglikha ng isang proyekto ng Java (nasa dulo ang mga link sa iba pang mga materyales). Ang layunin nito ay pag-aralan ang mga pangunahing teknolohiya, ang resulta ay pagsulat ng isang telegram bot. Pagbati, mahal na mga mambabasa. Gaya ng inilarawan sa nakaraang bahagi, pupunta tayo ayon sa plano. Nakagawa na kami ng isang proyekto at oras na para punan ito ng code. Ngayon ang lahat ng mga isyu ay idaragdag bilang mga hiwalay na commit. Ilalarawan ko ang lahat ng kailangan dito. Kung may napalampas akong isang bagay o hindi ito malinaw na ilarawan, magtanong sa mga komento, susubukan kong sagutin.

Nagsusulat kami ng JRTB-0M

Sa gawaing ito kailangan naming magdagdag ng walang laman na SpringBoot framework para sa hinaharap na trabaho. Gagawin namin ito sa parehong paraan tulad ng ginawa namin sa artikulo tungkol sa SpringBoot + Flyway . I-download ang proyekto , buksan ito sa IDEA at lumikha ng bagong sangay na tinatawag na JRTB-0 . Inilarawan ko kung paano ito gagawin sa pamamagitan ng isang ideya dito . Gagawin nitong mas madali para sa amin na subaybayan ang trabaho sa hinaharap. Alam mo na ba na wala nang master branch? Ngayon ito ay tinatawag na neutrally - main . Kaya nasanay na tayo. Bagaman, sa totoo lang, maaari nating palitan ito ng pangalan pabalik sa master. Pumunta kami sa Spring Initializr at lumikha ng SpringBoot framework para sa aming bot. Sa ngayon, ang pinakabatang bersyon ng boot sprint na inaalok ay 2.3.7, kunin natin ito. Ilalarawan ko nang hiwalay ang mga sumusunod na setting:

• Project: Maven Project - napag-usapan na natin si Maven dito at dito . Samakatuwid, ilalarawan ko lamang kung ano ang hindi ko ibinunyag sa mga nakaraang artikulo. Kung mayroong gayong "mga puting spot", siyempre)
• Wika: Java - malinaw ang lahat dito. Kung may pagnanais, maaari naming muling isulat ang bagay na ito sa Kotlin. Kakabili ko lang ng librong Kotlin in Action, sabay nating matutunan ang Kotlin))
• Spring Boot: 2.3.7 - kinukuha namin ang pinakamaliit na bersyon na inaalok upang maalis ang anumang mga problema. Isa na itong ganap na modernong bersyon ng boot.

Metadata ng Proyekto:

• Pangkat: com.github.javarushcommunity - dito pipiliin namin ang domain kung saan naka-host ang aming pangkat ng mga repositoryo.
• Artifact: javarush-telegrambot - maximum na paglalarawan ng proyekto.
• Pangalan: Javarush TelegramBot - isusulat namin ito nang buo dito.
• Paglalarawan: Telegram bot para sa Javarush mula sa komunidad patungo sa komunidad - narito ang isang mas detalyadong paglalarawan ng proyekto.
• Pangalan ng package: com.github.javarushcommunity.jrtb - dito maaari ka nang gumamit ng abbreviation para sa pangalan ng proyekto. Ngayon ang proyekto ay magsisimula sa paketeng ito. Bakit ang dami? Upang kapag nagdagdag kami ng iba pang mga proyekto sa classpath, sila ay nasa iba't ibang mga pakete. Ang bawat isa sa kanilang sariling natatanging paraan. Mahalaga ito upang mapanatili ang mga prinsipyo ng OOP.
• Packaging: Jar ang aming pamantayan)
• Java: 11 - mauuna tayo ng isang hakbang. Sa palagay ko ay hindi ako gagamit ng mga inobasyon pagkatapos ng ikawalong Java, ngunit hayaan mo na. Hindi siya humihingi ng pagkain)... ang desisyong ito ay magbibigay sa atin ng isang maliit na Easter egg sa hinaharap)

Hindi kami magdaragdag ng anumang mga dependency sa ngayon. Hindi namin ito kailangan para sa gawaing ito. Matapos mapunan ang lahat ng ito, nakukuha namin (narito ang isang link sa nabuong proyekto): Kapag napunan, i-click ang GENERATE at idagdag ang lahat ng mga internal sa archive sa aming proyekto. Magdagdag ng mga file sa proyekto. Bilang resulta, mayroon kaming isang aplikasyon. Upang suriin kung ito ay binuo sa lahat, pumunta sa terminal at isulat ang: $ mvn malinis na pakete Kung mayroon kang katulad ng mula dito, ang lahat ay ok: ang proyekto ay binuo, at ang jarnik ay handa na sa target na folder. Sa puntong ito, handa na ang gawain sa loob ng paglalarawan. Simple lang diba? Samakatuwid, kami ay nangangako at nagtutulak sa aming sangay: Idinaragdag namin ang pangalan ng aming gawain sa simula ng paglalarawan ng commit, upang sa ibang pagkakataon ay maging malinaw sa loob ng balangkas kung aling gawain ang ginawa. I-click ang Commit at Push ... Muli naming sinusuri at tinitingnan kung ano ang eksaktong gusto naming itulak mula sa lokal na repositoryo patungo sa remote at, tinitiyak na ok ang lahat, i-click ang Push . Ano ang ating susunod na hakbang? Ayon sa lahat ng mga patakaran (na mababasa sa artikulong ito , sa bahagi tungkol sa daloy ng GitHub), kailangan mong gumawa ng pull request para sa pangunahing sangay at maghintay para sa isang tao mula sa koponan na suriin ang code. Dahil nag-iisa ako, pormal akong gagawa ng pull request at susuriin muli ang lahat. Pumunta ako sa pahina ng repositoryo, at alam na ng Github na mayroon kaming karagdagan at nag-aalok upang lumikha ng kahilingan sa paghila: Walang mga hadlang para sa mga makabayan (c) - nilikha namin ito, tulad ng iminungkahing. Itinakda namin ang parehong label, proyekto tulad ng sa gawaing ginagawa namin, at punan ang paglalarawan: I-click ang Lumikha ng pull request .

Pagse-set up ng proseso ng CI

Pumunta kami sa ginawang pull request: sa ibaba makikita namin na wala kaming Continuous Integration na na-configure (simula dito - CI). Well, hindi ito naka-configure, kaya ano? Bakit kailangan natin ng CI? Ano naman ang CI? Ito ay humigit-kumulang sa listahan ng mga tanong na dapat nating alalahanin sa sandaling ito. Sa pangkalahatan, ang CI ay isang tuluy-tuloy na proseso ng pagsasama ng code sa isang karaniwang base ng code at pagpapatakbo ng isang build ng proyekto bago iyon. Ang tinatawag na build (mula sa English build). Sa bawat oras na bumuo kami ng isang proyekto, tinitiyak namin na ang proyekto ay pinagsama-sama, ang lahat ng mga pagsubok nito ay matagumpay na naipasa, at pagkatapos mabuo ang proyekto, maaari kang magdagdag ng mga autotest mula sa mga tester hanggang sa CI na pinapatakbo sa partikular na build na ito. Sa ganitong paraan, mas nagiging kumpiyansa tayo na gumagana ang mga bagong pagbabago gaya ng inaasahan namin at hindi sinisira ang dating functionality. Maganda rin ang CI dahil awtomatiko itong magsisimula pagkatapos i-update ang code base. Iyon ay, itinulak namin ang aming mga pagbabago sa sangay at nagsimula ang proseso - pagpupulong, mga pagsubok, mga autotest at iba pang mga hakbang. Kung mabigo ang alinman sa mga hakbang na ito, ituturing na sira ang build at hindi maaaring isama sa pangunahing sangay. Ito mismo ang gagawin namin ngayon: magdaragdag kami ng GitHub Actions, na tatakbo sa aming code pagkatapos ng push. Akmang-akma ang GitHub Actions sa aming GitHub Flow, kaya gagamitin namin ito para i-automate ang aming trabaho. Ang tool na ito ay napakalakas at malaki, ngunit sa ngayon ay gagamitin lamang namin ito upang patakbuhin ang build at suriin kung ito ay binuo kung kinakailangan. Upang paganahin ito, hanapin ang button na Mga Pagkilos sa pahina ng repositoryo at sundan ito: Hanapin ang Trabaho ng Patuloy na Pagsasama na kailangan namin: I-click ang I-set up ang workflow na ito. Susunod, inaalok kaming gamitin ang kanilang template: lubos kaming sumasang-ayon, linawin lang natin nang kaunti ang lahat:

# 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

Ito ay nagpapahiwatig na ang GitHub Action ay tinatawag sa dalawang kaso:

1. Kapag ang isang push ay ginawa sa pangunahing sangay.
2. Kapag ang isang pull request ay ginawa sa pangunahing sangay.

Inilalarawan ng seksyon ng mga trabaho ang mga hakbang na isasagawa. Mayroon lamang kaming isang hakbang - bumuo. Ipinapakita nito na ang aming proyekto ay ilulunsad sa Ubuntu gamit ang command na mvn -B package --file pom.xml . Ito ay eksakto kung ano ang ginawa namin sa lokal. Kung may gusto kang baguhin dito, pakiusap. Gagamitin ko ang template na ito, ito ay sapat na para sa akin. I-click ko ang Start commit , piliin ang lumikha ng isang bagong sangay upang i - configure ang proseso at pagkatapos ay Magmungkahi ng bagong file . Ngunit ang proseso ng pagbuo ay nahulog ... Tulad ng nakikita mo, Nabigo pagkatapos ng 14s - bumuo. Mukhang may nangyari: lumipat tayo sa pagpupulong at tingnan ang mga detalye: Sinasabi nito na hindi ko mahanap ang gayong alaala. Bakit? Ahhh, eksakto, eksakto! Dahil gumawa kami ng mga pagbabago sa master branch, ngunit ang aming gawain ay wala pa doon. At iyon ang dahilan kung bakit hindi niya nahanap ang memorya... Samakatuwid, ngayon ginagawa namin ang sumusunod: pinagsama namin ang data na ito sa master, pagkatapos ay pinagsama namin ang pangunahing sangay sa JRTB-0, at pagkatapos ay dapat na maayos ang lahat. Sa isang pull request na may mga pagbabago sa github actions, i-click ang Merge pull request : At ulitin ang Kumpirmahin ang merge . Susunod, sinenyasan kami ng Github na tanggalin ang sangay kung saan kami nagtrabaho. Hindi kami tumatanggi at nagtatanggal: Susunod, hindi ko nakita sa pull request mula sa SpringBoot kung paano mag-pull ng mga pagbabago mula sa pangunahing sangay mula sa website, kaya gagawin namin ito nang manu-mano sa pamamagitan ng IDEA.

Hakbang 1: I-update ang master branch sa lokal na repository.

Ang ideya ay pumunta sa master branch, pindutin ang ctrl + t at i-update ang master branch:

Hakbang 2: Pagsamahin ang mga pagbabago mula sa master branch patungo sa JRTB-0 branch.

Pumunta tayo sa JRTB-0 at pagsamahin ang pangunahing isa dito.

Hakbang 3: itulak ang mga pagbabago.

Pindutin ang ctrl + shift + k at kumpirmahin ang push. Ngayon ay hinihintay namin na pumasa ang build at ito ay magiging berde!)) Ngunit ito ay pula muli. Ano ito? Pumunta kami sa mga log ng aksyon at makita na wala kaming sync sa mga bersyon ng Java. Sa GitHubActions ito ay 8, ngunit ginagamit namin ang 11: Ngayon ay may dalawang pagpipilian: alinman sa itama ang mga aksyon, o ibaba ang bersyon sa ikawalo. Ang unang pagpipilian, tila sa akin, ay mas mahusay at mas tama. Gumagawa kami ng mga pagbabago sa isang hiwalay na commit: gagana kami hindi sa Java 8, ngunit sa Java 11. At pagkatapos noon, sa wakas, naging maayos ang lahat para sa amin, at nagawa naming i-set up ang aming proseso ng CI para sa proyekto. Ang mga ganitong bagay ay kailangang i-set up sa paunang yugto, upang hindi mo na kailangang mag-alala tungkol dito sa ibang pagkakataon. Ngayon ay makikita mo na ang build ay lumipas na at maaari mong pagsamahin nang walang takot:

Pagse-set up ng trabaho sa mga sangay sa imbakan

Maaari mo ring i-configure ang mga bagay sa repository bilang mga panuntunan kapag nagtatrabaho sa mga sangay. Nais kong gawin ito upang ang pangunahing sangay ay hindi maitulak nang direkta, ngunit sa pamamagitan lamang ng mga kahilingan sa paghila, at nais kong gawin ito upang imposibleng pagsamahin ang isang kahilingan sa paghila kung nabigo ang pagbuo (iyon ay, kung nabigo ang GitHub Actions sa ilang hakbang). Upang gawin ito, hanapin ang pindutan ng Mga Setting at piliin ang Mga Sangay : Sa ngayon ay walang mga panuntunan para sa mga sangay, kaya't magdagdag tayo ng bago sa pamamagitan ng pindutan ng Magdagdag ng panuntunan : Maraming mga setting dito, at lahat ay maaaring gumawa ng isang bagay upang umangkop sa kanilang pangangailangan. Upang matagumpay na makapasa ang build sa kahilingan sa paghila bago pagsamahin, magdagdag ng checkbox sa Mangailangan ng mga pagsusuri sa katayuan na pumasa bago pagsamahin at piliin ang katayuan na kailangan namin - buuin. Sapat na iyon sa ngayon: pagkatapos ay maaari mong i-update ang manibela na ito at makita kung ano pa ang gusto mo. I-click ang Gumawa para gawin itong manibela. Susunod, kung pupunta tayo muli sa ating pull request, makikita natin na ang ating tseke ay minarkahan na ngayon na kailangan: Suriin natin ang aming pahina ng proyekto, na nagpapakita ng lahat ng mga katayuan ng gawain: Makikita mo kaagad kung anong gawain ang ginagawa. Bukod dito, ang gawain ay tapos na, at ang gawain ay nasa status ng pagsusuri ng code.

Isinasara ang JRTB-0

Ngayong nakapaghanda na kami ng pull request at gumawa ng CI para dito, kailangan naming kumpletuhin ang huling yugto: isara ang gawain, ilipat ito sa tamang katayuan, tingnan ang mga pagbabago sa aming proyekto sa board. Ang aming kahilingan sa paghila ay handa nang i-merge sa master. Sa pull request, i-click ang I-merge ang pull request na button : Pagkatapos ng matagumpay na pagsasama, maaari mo itong tanggalin, at kadalasan ay ginagawa ito. Hindi ko ito gagawin para mas madali mong makita ang mga pagbabago sa pagitan ng mga branch/commit. Sa sandaling pinagsama ang isang pull request, awtomatiko itong mapupunta sa aming project board: Ang huling hakbang ay upang isara ang isyu (isyu) gamit ang isang link sa pull request kung saan ito ay: Ang isyu na ito ay awtomatikong napupunta sa tapos na board. Ang simula ay ginawa, ang unang gawain ay tapos na!

mga konklusyon

Mukhang nagsimula na kaming magtrabaho at magsulat ng code, ngunit kailangan pa rin ang mga setting. Oo, ito ay tumatagal ng oras, ngunit ito ay magbabayad ng isang daang beses kapag ang proyekto ay naging mas malaki at mas kumplikado at kailangan mo ng mga garantiya na hindi mo masisira ang lahat sa isang pangako. Available dito ang pull request kung saan nangyayari ang lahat ng ito . Marahil, kapag binasa mo, ito ay sarado na. Hindi ito nakakatakot: lahat ng kinakailangang impormasyon ay maiimbak sa pamamagitan ng link. Salamat sa lahat ng nagbabasa, see you soon. At saka!

Ang isang listahan ng lahat ng mga materyales sa serye ay nasa simula ng artikulong ito.