🥇Guide til CI\/CD i GitLab for (næsten) totale nybegyndere

Eller hvordan man får smukke badges til sit projekt på en aften med afslappet kodning

For hver udvikler, der har mindst ét pet-projekt, opstår der på et tidspunkt et behov for smukke badges med statusser, kode dækning, versioner af pakker i nuget... Og dette behov førte mig til at skrive denne artikel. I forberedelsen til at skrive den, fik jeg således en skønhed i et af mine projekter:

Artiklen vil behandle grundlæggende opsætning af kontinuerlig integration og levering for et klass biblioteksprojekt på .Net Core i GitLab, med publicering af dokumentation i GitLab Pages og overførsel af de samlede pakker til et privat feed i Azure DevOps.

Der blev anvendt VS Code som udviklingsmiljø med udvidelsen GitLab Workflow (til validering af konfigurationsfilen direkte fra udviklingsmiljøet).

Kort introduktion

CD — det er når du lige har pushet, og kunden allerede har problemer?

Hvad CI/CD er, og hvorfor det er nødvendigt — kan nemt findes på nettet. Det er heller ikke svært at finde dokumentation for opsætning af pipelines i GitLab her. Her beskriver jeg kort og så fejlfrit som muligt arbejdsprocessen i systemet fra et fugleperspektiv:udvikleren sender et commit til depotet, opretter en merge request via hjemmesiden,

eller på en anden måde eksplicit eller implicit starter pipeline fra konfigurationen vælges alle opgaver, hvis betingelser tillader dem at starte i den givne kontekst,,
opgaverne organiseres i henhold til deres faser,
faserne udføres én ad gangen — dvs.
parallelt udføres alle opgaver i denne fase, hvis en fase mislykkes (dvs. hvis mindst én opgave i fasen mislykkes) — stopper pipeline (
næsten altidhvis alle faser afsluttes med succes, betragtes pipeline som succesfuldt bestået.),
Således har vi:

pipeline — et sæt opgaver, organiseret i faser, hvor man kan bygge, teste, pakke koden, implementere den færdige samling i en cloud service, og meget mere,

fase (
) — en enhed til organisering af pipeline, indeholder 1+ opgaver,stageopgave (
job) — en enhed for arbejde i pipeline. Består af et script (obligatorisk), startbetingelser, indstillinger for publicering/cache af artefakter og meget andet.) — enhed i pipeline. Består af et script (obligatorisk), betingelser for aktivering, indstillinger for publicering/cachelagring af artefakter og meget mere.

Derfor er opgaven med at konfigurere CI/CD at oprette et sæt opgaver, der udfører alle nødvendige handlinger til at bygge, teste og offentliggøre kode og artefakter.

Inden vi begynder: hvorfor?

Hvorfor GitLab?

Fordi da behovet opstod for at oprette private repositorier til pet-projekter, var de betalt på GitHub, og jeg - er økonomisk bevidst. Repositorier blev gratis, men det er ikke tilstrækkeligt for mig til at flytte til GitHub.

Hvorfor ikke Azure DevOps Pipelines?

Fordi opsætningen der er simpel - selv viden om kommandolinjen er ikke nødvendig. Integration med eksterne Git-udbydere er kun et par klik væk, import af SSH-nøgler til at sende commits til repositoriet er også let, og pipeline kan nemt konfigureres selv uden en skabelon.

Udgangspunkt: hvad vi har, og hvad vi ønsker

Vi har:

et repository i GitLab.

Vi ønsker:

automatisk bygning og test for hver merge request,
pakkeopbygning for hver merge request og push til master, betinget af at en bestemt sætning er i commit-beskeden,
afsendelse af de byggede pakker til en privat feed i Azure DevOps,
opbygning af dokumentation og offentliggørelse i GitLab Pages,
badges!11

De beskrevne krav passer godt ind i følgende pipeline-model:

Trin 1 - bygning
- Vi bygger koden, og output-filerne offentliggøres som artefakter
Trin 2 - testning
- Vi får artefakterne fra bygge-trinet, kører tests og samler kodedækning data
Trin 3 - afsendelse
- Opgave 1 - vi bygger nuget-pakken og sender den til Azure DevOps
- Opgave 2 - vi bygger et website fra xmldoc i kildekoden og offentliggør det i GitLab Pages

Lad os komme i gang!

Vi samler konfigurationen

Vi forbereder konti

Vi opretter en konto i Microsoft Azure
Vi går til Azure DevOps
Vi opretter et nyt projekt
1. Navn - vilkårligt
2. Synlighed - hvilken som helst
Når du trykker på knappen Opret, vil projektet blive oprettet, og der vil blive skiftet til dets side. På denne side kan du deaktivere unødvendige funktioner ved at gå til projektindstillingerne (den nederste link i venstre liste -> Oversigt -> blok Azure DevOps Services)
Vi går til Artifacts, klikker Opret feed
1. Vi indtaster kildens navn
2. Vi vælger synlighed
3. Vi fjerner fluebenet Inkluder pakker fra almindelige offentlige kilder, så kilden ikke bliver en skraldespand for kloner af nuget
Vi klikker på forbind til feed, vælger Visual Studio, kopierer Kilde fra blokken Maskinopsætning
Vi går til kontoinstillingerne, vælger Personlig adgangstoken
Vi opretter en ny adgangstoken
1. Navn - vilkårligt
2. Organisation - nuværende
3. Udløbsdato - maksimum 1 år
4. Område (scope) — Packaging/Read & Write
Vi kopierer den oprettede token — efter lukningen af den modale vindue vil værdien ikke være tilgængelig
Vi går ind i repository-indstillingerne i GitLab, vælger CI/CD-indstillingerne
Vi udvider blokken Variabler, tilføjer en ny
1. Navn — hvilket som helst uden mellemrum (vil være tilgængeligt i kommandolinjen)
2. Værdi — adgangstoken fra punkt 9
3. Vælg Mask variable

Den forberedende opsætning er nu afsluttet.

Vi forbereder konfigurationsrammen

Som standard anvendes filen til opsætning af CI/CD i GitLab .gitlab-ci.yml fra rodmappen i repositoryet. Du kan konfigurere en vilkårlig sti til denne fil i repository-indstillingerne, men det er ikke nødvendigt i dette tilfælde.

Som det fremgår af filtypen, indeholder filen konfigurationen i formatet YAML. Dokumentationen beskriver grundigt, hvilke nøgler der kan være på det øverste niveau af konfigurationen og i hvert af de indlejrede niveauer.

Først tilføjer vi et link til docker-billedet i konfigurationsfilen, hvor opgaverne vil blive udført. For dette finder vi siden med .Net Core-billeder på Docker Hub. I GitHub der er en detaljeret vejledning om, hvilket billede der skal vælges til forskellige opgaver. Til bygning anvender vi billedet med .Net Core 3.1, så vi tilføjer det første linje i konfigurationen

image: mcr.microsoft.com/dotnet/core/sdk:3.1

Nu, når pipelinen starter med lageret af Microsoft-billeder, vil det angivne billede blive downloadet, og alle opgaver fra konfigurationen vil blive udført.

Næste trin — tilføj stagefaser. Som standard definerer GitLab 5 faser:

.pre — udføres før alle faser,
.post — udføres efter alle faser,
build — den første efter .pre fase,
test — anden fase,
deploy — tredje fase.

Der er intet, der forhindrer at erklære dem eksplicit. Den rækkefølge, som faserne er angivet i, påvirker rækkefølgen, hvori de udføres. For fuldstændighedens skyld, lad os tilføje til konfigurationen:

stages:
  - build
  - test
  - deploy

For fejlfinding er det fornuftigt at få oplysninger om miljøet, hvor opgaverne udføres. Lad os tilføje et globalt sæt kommandoer, der vil blive udført før hver opgave, med hjælp fra before_script:

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

Vi skal nu tilføje mindst en opgave, så pipelinen bliver aktiveret ved commit. Indtil videre tilføjer vi en tom opgave til demonstration:

dummy job:
  script:
    - echo ok

Vi starter valideringen, får meddelelsen om, at alt er godt, committer, pushover, ser resultaterne på hjemmesiden... Og får en skriptfejl — bash: .PSVersion: kommando ikke fundet. Hvad fanden?

Det giver mening — som standard bruger runnerne (der står for udførelsen af opgave-scripts, og som leveres af GitLab) bash til at udføre kommandoer. Dette kan rettes ved tydeligt at angive i opgavebeskrivelsen, hvilke tags der skal være på den eksekverende pipeline-runner:

dummy job på windows:
  script:
    - echo ok
  tags:
    - windows

Fantastisk! Nu kører pipelinen.

En opmærksom læser, der følger de angivne trin, vil bemærke, at opgaven blev udført i trin test, selvom vi ikke angav trin. Hvordan kan vi deducere, test er det standardtrinnet.

Lad os fortsætte med at oprette skeletkonfigurationen ved at tilføje alle opgaverne beskrevet ovenfor:

build job:
  script:
    - echo "building..."
  tags:
    - windows
  stage: build

test and cover job:
  script:
    - echo "running tests and coverage analysis..."
  tags:
    - windows
  stage: test

pack and deploy job:
  script:
    - echo "packing and pushing to nuget..."
  tags:
    - windows
  stage: deploy

pages:
  script:
    - echo "creating docs..."
  tags:
    - windows
  stage: deploy

Vi fik en ikke særlig funktionel, men alligevel korrekt pipeline.

Opsætning af triggere

Da der ikke er angivet nogen triggere for hverken opgave, vil pipelinen helt blive udført ved hver commit til depotet. Da dette ikke er ønsket adfærd i almindelighed, vil vi indstille triggere for opgaverne.

Filtre kan konfigureres i to formater: only/except og rules. Kort sagt, only/except muliggør indstilling af filtre baseret på triggere (merge_request, for eksempel — indstiller opgaven til at køre ved hver oprettelse af en pull request og ved hver commit til den gren, der er basis i pull requesten) og gren navne (inklusive med brug af regulære udtryk); rules giver mulighed for at indstille et sæt betingelser og, valgfrit, ændre betingelsen for udførelsen af opgaven afhængigt af succes fra tidligere opgaver (block i GitLab CI/CD).

Lad os huske på kravene — bygning og test kun for merge requests, pakning og deployment til Azure DevOps — for merge requests og pushes til master, generering af dokumentation — for pushes til master.

Først skal vi konfigurere code build-opgaven ved at tilføje en triggerregel kun for merge requests:

build job:
  # snip
  only:
    - merge_request

Nu konfigurerer vi pack and deploy-opgaven til at aktivere på merge requests og commits til master:

pack and deploy job:
  # snip
  only:
    - merge_request
    - master

Som man kan se, er det helt enkelt og ligetil.

Du kan også konfigurere opgaven til at udløse kun, hvis der er oprettet en merge request med en bestemt mål- eller kildegren:

  regler:
    - hvis: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"

I betingelserne kan der bruges de nævnte variabler; regler rules er ikke kompatible med reglerne only/except.

Konfiguration af artefaktbesparelser

Under udførelsen af opgaven build job vil vi skabe byggeartefakter, som kan genbruges i efterfølgende opgaver. For at gøre dette skal du tilføje stier til konfigurationen af opgaven, filer der skal gemmes og genbruges i de efterfølgende opgaver, under nøglen artifacts:

build job:
  # snip
  artifacts:
    paths:
      - path/to/build/artifacts
      - another/path
      - MyCoolLib.*/bin/Release/*

Stier understøtter wildcards, hvilket bestemt forenkler deres angivelse.

Hvis opgaven opretter artefakter, vil hver efterfølgende opgave kunne få adgang til dem — de vil være placeret på de samme stier i forhold til rodmappen i repositoryet, som de blev samlet fra den oprindelige opgave. Artefakterne er også tilgængelige for download på hjemmesiden.

Nu hvor vi har den (og den er blevet kontrolleret) konfiguration grundlag klar, kan vi begynde selve skrivningen af scripts til opgaverne.

Skriver scripts

Måske, engang i en fjern, fjern galakse, var det svært at samle projekter (herunder også .net) fra kommandolinjen. Nu kan man dog samle, teste og udgive et projekt med 3 kommandoer:

dotnet build
dotnet test
dotnet pack

Naturligvis er der nogle nuancer, som gør, at vi komplicerer kommandoerne en smule.

Vi vil have en release-udgave, og ikke en debug-udgave, så vi tilføjer -c Release
Når vi tester, ønsker vi at samle data om kode dækning, så vi skal tilføje en dækning analyzer til testbibliotekerne:
1. Alle testbiblioteker skal tilføje pakken coverlet.msbuild: dotnet add package coverlet.msbuild fra projektmappen
2. Til kommandoen til at køre testene tilføjer vi /p:CollectCoverage=true
3. I konfigurationen af testopgaven tilføjer vi en nøgle til at hente dækningen resultater (se nedenfor)
Når vi pakker koden i nuget-pakker, angiver vi output-mappen for pakkerne: -o .

Samler data om kode dækning

Coverlet viser efter kørsel af testene statistikken for kørslen i konsollen:

Beregningsresultat for dækning...
  Generer rapport 'C:Usersxxxsourcereposmy-projectmyProject.testscoverage.json'

+-------------+--------+--------+--------+
| Modul       | Linje  | Gren   | Metode |
+-------------+--------+--------+--------+
| projekt 1   | 83,24% | 66,66% | 92,1%  |
+-------------+--------+--------+--------+
| projekt 2   | 87,5%  | 50%    | 100%   |
+-------------+--------+--------+--------+
| projekt 3   | 100%   | 83,33% | 100%   |
+-------------+--------+--------+--------+

+---------+--------+--------+--------+
|         | Linje  | Gren   | Metode |
+---------+--------+--------+--------+
| Total   | 84,27% | 65,76% | 92,94% |
+---------+--------+--------+--------+
| Gennemsnit | 90,24% | 66,66% | 97,36% |
+---------+--------+--------+--------+

GitLab gør det muligt at angive et regulært udtryk for at hente statistikker, som derefter kan vises i form af et badge. Det regulære udtryk angives i opgaveindstillingerne med nøgle coverage; udtrykket skal indeholde en capture-gruppe, hvis værdi vil blive sendt til badget:

test og dæk job:
  # snip
  dækning: \/|s*Totaler*|s*(d+[,.]d+%)\/

Her får vi statistikken fra den samlede dækning ved linjer.

Vi publicerer pakker og dokumentation

Begge handlinger er sat til den sidste fase af pipeline – da bygningen og testene er gennemført, kan vi dele vores resultater med verden.

Lad os starte med at se på publicering i pakke kilden:

Hvis projektet ikke har en nuget konfigurationsfil (nuget.config), så lad os oprette en ny: dotnet new nugetconfig
Hvorfor: i billedet kan der være forbudt skrivning til de globale (bruger- og maskin-) konfigurationer. For ikke at få fejl, lad os blot oprette en ny lokal konfiguration og arbejde med den.
Lad os tilføje en ny pakke kilde til den lokale konfiguration: nuget sources add -name <name> -source <url> -username <organization> -password <gitlab variable> -configfile nuget.config -StorePasswordInClearText
1. name — lokalt navn på kilden, ikke vigtigt
2. url — URL på kilden fra trin 'Forbereder konti', p. 6
3. organisation — navnet på organisationen i Azure DevOps
4. gitlab variable — navnet på variablen med adgangstokenet, tilføjet i GitLab ('Forbereder konti', p. 11). Selvfølgelig i formatet $variableName
5. -StorePasswordInClearText — hack til at omgå adgang nægtet fejl (jeg er ikke den første, der er trådt i denne fælde)
6. For fejl kan det være nyttigt at tilføje -verbosity detailed
Sender pakken til kilden: nuget push -source <name> -skipduplicate -apikey <key> *.nupkg
1. Vi sender alle pakker fra den nuværende mappe, så *.nupkg.
2. name — fra trin ovenfor.
3. nøgle — hvilken som helst streng. I Azure DevOps vise 'Connect to feed' altid som et eksempel den strengen az.
4. -skipduplicate — når man forsøger at sende en allerede eksisterende pakke, vil kilden returnere en fejl uden denne nøgle 409 Konflikt; med nøgle vil indsendelsen blive sprunget over.

Lad os nu konfigurere oprettelsen af dokumentation:

For at starte, i depotet, i master-grenen, initialiserer vi docfx-projektet. For dette skal vi køre kommandoen fra roden docfx init og i interaktiv tilstand angive nøgleparametre til opbygningen af dokumentationen. En detaljeret beskrivelse af minimal configuration af projektet her.
1. Når du konfigurerer, er det vigtigt at angive outputmappen ..public — GitLab bruger som standard indholdet af public-mappen i rodmappen til depotet som kilde til Pages. Da projektet vil være placeret i en undermappe af depotet — tilføjer vi en sti op en niveau.
Lad os sende ændringerne til GitLab.
I pipeline-konfigurationen tilføjer vi opgaven pages (reserveret ord for opgaver til publicering af websteder i GitLab Pages):
1. Script:
  1. nuget install docfx.console -version 2.51.0 — vil installere docfx; versionen er angivet for at sikre, at installationsstierne er korrekte.
  2. .docfx.console.2.51.0toolsdocfx.exe .docfx_projectdocfx.json — vi samler dokumentationen
2. Artifacts-node:

pages:
  # snip
  artifacts:
    paths:
      - public

Lirerisk afstikker omkring docfx

Tidligere, da jeg konfigurerede projektet, angav jeg kildekoden til dokumentationen som en løsningsfil. Den primære ulempe er, at dokumentationen også genereres for testprojekter. Hvis dette ikke er nødvendigt, kan du angive sådan en værdi for noden metadata.src:

{
  "metadata": [
    {
      "src": [
        {
          "src": "..\/",
          "files": [
            "**\/*.csproj"
          ],
          "exclude":[
            "*.tests*\/**"
          ]
        }
      ],
      \/\/ --- snip ---
    },
    \/\/ --- snip ---
  ],
  \/\/ --- snip ---
}

metadata.src.src: "..\/" — vi går et niveau op i forhold til placeringen docfx.json, da søgningen opad i mappetræet ikke fungerer i mønstrene.
metadata.src.files: ["**\/*.csproj"] — globalt mønster, vi samler alle C# projekter fra alle mapper.
metadata.src.exclude: ["*.tests*\/**"] — globalt mønster, vi udelukker alt fra mapper med .tests i navnet.

Mellemsum

Sådan en simpel konfiguration kan sammensættes på bare en halv time og et par kopper kaffe, som vil sikre, at ved hver forespørgsel om sammensmeltning og indsendelse til master kontrolleres, at koden bygger, og at testene består, opbygges en ny pakke, opdateres dokumentationen og fortryder øjet med smukke badges i projektets README.

Den endelige .gitlab-ci.yml

image: mcr.microsoft.com/dotnet/core/sdk:3.1

before_script:
  - $PSVersionTable.PSVersion
  - dotnet --version
  - nuget help | select-string Version

stages:
  - build
  - test
  - deploy

build job:
  stage: build
  script:
    - dotnet build -c Release
  tags:
    - windows
  only:
    - merge_requests
    - master
  artifacts:
    paths:
      - your/path/to/binaries

test and cover job:
  stage: test
  tags:
    - windows
  script:
    - dotnet test -c Release /p:CollectCoverage=true
  coverage: /|s*Totals*|s*(d+[,.]d+%)//
  only:
    - merge_requests
    - master

pack and deploy job:
  stage: deploy
  tags:
    - windows
  script:
    - dotnet pack -c Release -o .
    - dotnet new nugetconfig
    - nuget sources add -name feedName -source https://pkgs.dev.azure.com/your-organization/_packaging/your-feed/nuget/v3/index.json -username your-organization -password $nugetFeedToken -configfile nuget.config -StorePasswordInClearText
    - nuget push -source feedName -skipduplicate -apikey az *.nupkg
  only:
    - master

pages:
  tags:
    - windows
  stage: deploy
  script:
    - nuget install docfx.console -version 2.51.0
    - $env:path = "$env:path;$($(get-location).Path)"
    - .docfx.console.2.51.0toolsdocfx.exe .docfxdocfx.json
  artifacts:
    paths:
      - public
  only:
    - master

For øvrigt om badges

Det var jo for dem, at hele dette blev startet!

Badges med status for pipeline og dækning af kode er tilgængelige i GitLab under CI/CD-indstillingerne i blokken Gtntral pipelines:

Badgen med et link til dokumentationen oprettede jeg på platformen Shields.io — det er ret ligetil, man kan oprette sin egen badge og hente den med en forespørgsel.

![Eksempel med Shields.io](https://img.shields.io/badge/custom-badge-blue)

Azure DevOps Artifacts giver også mulighed for at oprette badges for pakker med angivelse af den aktuelle version. For at gøre dette skal du på Azure DevOps webstedet trykke på Create badge for den valgte pakke og kopiere markdown-notationen:

Lad os tilføje lidt skønhed

Vi fremhæver fælles konfigurationsfragmenter

Mens jeg skrev konfigurationen og søgte i dokumentationen, stødte jeg på en interessant mulighed i YAML — genbrug af fragmenter.

Som det ses fra indstillingerne for opgaverne, kræver de alle et tag windows på runneren, og de udløses ved at sende til master/oprette en pull-anmodning (undtagen dokumentationen). Lad os tilføje dette til det fragment, som vi vil genbruge:

.common_tags: &common_tags
  tags:
    - windows
.common_only: &common_only
  only:
    - merge_requests
    - master

Og nu kan vi indsætte det tidligere nævnte fragment i beskrivelsen af opgaven:

build job:
  <<: *common_tags
  <<: *common_only

Navnene på fragmenterne skal begynde med et punktum for ikke at blive fortolket som en opgave.

Versionering af pakker

Når et paket oprettes, kontrollerer compileren kommandolinjens nøgler, og i deres fravær projektfilerne; når den finder noden Version, tager den dens værdi som versionen af det samlede paket. For at samle et paket med en ny version er det nødvendigt enten at opdatere den i projektfilen eller at overføre den som et kommandolinjeargument.

Lad os tilføje endnu et ønske — lad de to laveste numre i versionen være året og datoen for paketsamlingen, og lad os tilføje prerelease-versioner. Det er selvfølgelig muligt at tilføje disse data i projektfilen og kontrollere dem før hver upload — men det kan også gøres i pipeline, hvor versionen af pakken samles ud fra konteksten og overføres via et kommandolinjeargument.

Lad os enes om, at hvis der i commit-beskeden er en streng af typen release (v.\/ver.\/version) <versionsnummer> (rev.\/revision <revision>)?, så vil vi tage versionen af pakken fra denne streng, tilføre den nuværende dato og overføre den som et argument til kommandoen dotnet pack. I fravær af strengen vil vi simpelthen ikke samle pakken.

Den følgende script løser denne opgave:

# регулярное выражение для поиска строки с версией
$rx = "releases+(v.?|ver.?|version)s*(?<maj>d+)(?<min>.d+)?(?<rel>.d+)?s*((rev.?|revision)?s+(?<rev>[a-zA-Z0-9-_]+))?"
# ищем строку в сообщении коммита, передаваемом в одной из предопределяемых GitLab'ом переменных
$found = $env:CI_COMMIT_MESSAGE -match $rx
# совпадений нет - выходим
if (!$found) { Write-Output "no release info found, aborting"; exit }
# извлекаем мажорную и минорную версии
$maj = $matches['maj']
$min = $matches['min']
# если строка содержит номер релиза - используем его, иначе - текущий год
if ($matches.ContainsKey('rel')) { $rel = $matches['rel'] } else { $rel = ".$(get-date -format "yyyy")" }
# в качестве номера сборки - текущие месяц и день
$bld = $(get-date -format "MMdd")
# если есть данные по пререлизной версии - включаем их в версию
if ($matches.ContainsKey('rev')) { $rev = "-$($matches['rev'])" } else { $rev = '' }
# собираем единую строку версии
$version = "$maj$min$rel.$bld$rev"
# собираем пакеты
dotnet pack -c Release -o . /p:Version=$version

Tilføj scriptet til opgaven pakke og implementeringsjob og overvåge pakksamlingen strengt, når den angivne streng er til stede i commit-beskeden.

I alt

Efter at have brugt cirka en halv til en time på at skrive konfigurationen, debugge i lokal powershell og muligvis et par mislykkedes forsøg, har vi fået en enkel konfiguration til automatisering af rutineopgaver.

Selvfølgelig er GitLab CI\/CD meget mere omfattende og nuanceret, end det kan synes ved læsning af denne vejledning — det er slet ikke tilfældet. Derude er Auto DevOps, som gør det muligt

automatically detect, build, test, deploy, and monitor your applications

Nu er planen at konfigurere en pipeline til implementering af applikationer i Azure, med brug af Pulumi og automatisk bestemmelse af målmiljøet, hvilket vil blive dækket i den næste artikel.

Kilde: habr.com