Kaikki alkoi siitä, kun yhden kehitystiimimme tiiminvetäjä pyysi meitä testaamaan heidän uutta sovellustaan, joka oli konteissa edellisenä päivänä. Lähetin sen. Noin 20 minuutin kuluttua tuli pyyntö päivittää sovellus, koska sinne oli lisätty erittäin tarpeellinen asia. uusin. Muutaman tunnin kuluttua... no, voit arvata mitä seuraavaksi tapahtui...
Minun on myönnettävä, että olen melko laiska (enkö tunnustanut tämän aiemmin? Ei?), ja koska tiimin johtajilla on pääsy Jenkinsiin, jossa meillä on kaikki CI/CD, ajattelin: anna hänen ottaa käyttöön niin paljon kuin hän haluaa! Muistin vitsin: anna miehelle kala, niin hän syö yhden päivän; soita henkilölle Fediksi ja häntä syötetään koko ikänsä. Ja meni leikkiä temppuja työssä, joka voisi ottaa käyttöön kontin, joka sisältää minkä tahansa onnistuneesti rakennetun version sovelluksen Kuberiin ja siirtää kaikki arvot siihen ENV (Isoisäni, filologi, entinen englannin opettaja, pyöritteli nyt sormellaan temppeliään ja katsoi minua erittäin ilmeikkäästi tämän lauseen luettuaan).
Joten tässä muistiinpanossa kerron kuinka opin:
- Päivitä Jenkinsin työpaikat dynaamisesti itse työstä tai muista töistä;
- Yhdistä pilvikonsoliin (Cloud Shell) solmusta, johon on asennettu Jenkins-agentti;
- Ota työkuormitus käyttöön Google Kubernetes Engineen.
Itse asiassa olen tietysti hieman epäluuloinen. Oletetaan, että sinulla on ainakin osa infrastruktuurista Google-pilvessä, ja siksi olet sen käyttäjä ja sinulla on tietysti GCP-tili. Mutta siitä ei tässä muistiossa ole kyse.
Tämä on seuraava huijauslehteni. Haluan kirjoittaa tällaisia muistiinpanoja vain yhdessä tapauksessa: kohtasin ongelman, en aluksi tiennyt kuinka ratkaista se, ratkaisua ei googletettu valmiina, joten googletin sen osissa ja lopulta ratkaisin ongelman. Ja jotta jatkossa, kun unohdan miten tein, ei tarvitsisi googlettaa kaikkea pala palalta uudestaan ja koota yhteen, kirjoitan itselleni sellaisia huijauslehtiä.
Disclaimer: 1. Muistiinpano kirjoitettiin "itselleni", roolia varten parhaiden käytäntöjen ei päde. Olen iloinen voidessani lukea kommenteista "se olisi ollut parempi tehdä näin" -vaihtoehdot.
2. Jos nuotin käytettyä osaa pidetään suolana, niin tämä, kuten kaikki aikaisemmat nuotini, on heikko suolaliuos.
Työasetusten dynaaminen päivittäminen Jenkinsissä
Ennustan kysymyksesi: mitä tekemistä dynaamisella työnpäivityksellä on sen kanssa? Syötä merkkijonoparametrin arvo manuaalisesti ja lähde!
Vastaan: Olen todella laiska, en pidä siitä, kun he valittavat: Misha, käyttöönotto kaatuu, kaikki on poissa! Aloitat etsimisen ja jonkin tehtävän käynnistysparametrin arvossa on kirjoitusvirhe. Siksi teen mieluummin kaiken mahdollisimman tehokkaasti. Jos on mahdollista estää käyttäjää syöttämästä tietoja suoraan antamalla sen sijaan lista arvoista, joista valita, niin järjestän valinnan.
Suunnitelma on seuraava: luomme Jenkinsiin työpaikan, jossa ennen julkaisua voisimme valita listasta version, määrittää arvot säilöön välitetyille parametreille. ENV, sitten se kerää säilön ja työntää sen säilörekisteriin. Sitten sieltä kontti lasketaan liikkeelle cuber as työmäärä työssä määritellyillä parametreilla.
Emme harkitse työpaikan luomista ja perustamista Jenkinsissä, tämä ei kuulu aiheeseen. Oletetaan, että tehtävä on valmis. Päivitetyn versioluettelon toteuttamiseksi tarvitsemme kaksi asiaa: olemassa olevan lähdeluettelon, jossa on a priori kelvolliset versionumerot ja muuttuja, kuten Valintaparametri tehtävässä. Esimerkissämme muuttuja nimetään BUILD_VERSION, emme käsittele sitä yksityiskohtaisesti. Mutta katsotaanpa tarkemmin lähdeluetteloa.
Ei ole niin paljon vaihtoehtoja. Kaksi asiaa tuli heti mieleen:
- Käytä etäkäyttösovellusliittymää, jota Jenkins tarjoaa käyttäjilleen;
- Pyydä etävarastokansion sisältö (tapauksessamme tämä on JFrog Artifactory, mikä ei ole tärkeää).
Jenkins Remote Access API
Vakiintuneen erinomaisen perinteen mukaan vältän mieluummin pitkiä selityksiä.
Annan itselleni vain ilmaisen käännöksen osan ensimmäisestä kappaleesta :
Jenkins tarjoaa sovellusliittymän toimintojensa etäluettavaksi etäkäyttöä varten. <…> Etäkäyttöä tarjotaan REST-tyyliin. Tämä tarkoittaa, että kaikille ominaisuuksille ei ole yhtä sisääntulokohtaa, vaan URL-osoite, kuten ".../api/", Missä "..." tarkoittaa objektia, johon API-ominaisuuksia sovelletaan.
Toisin sanoen, jos käyttöönottotehtävä, josta tällä hetkellä puhumme, on saatavilla osoitteessa http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, tämän tehtävän API-pillit ovat saatavilla osoitteessa http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/
Seuraavaksi meillä on mahdollisuus valita, missä muodossa tuloste vastaanotetaan. Keskitytään XML:ään, koska API sallii vain suodatuksen tässä tapauksessa.
Yritetään vain saada luettelo kaikista suorituksista. Olemme kiinnostuneita vain kokoonpanon nimestä (näyttönimi) ja sen tulos (johtua):
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]Näytti siltä?
Suodatetaan nyt vain ne ajot, jotka päätyvät tulokseen MENESTYS. Käytetään argumenttia &sulje pois ja parametrina välitämme sille polun arvoon, joka ei ole yhtä suuri MENESTYS. Kyllä kyllä. Kaksinkertainen negatiivinen on väite. Suljemme pois kaiken, mikä ei kiinnosta meitä:
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS'] Kuvakaappaus onnistuneiden luettelosta
No, huvin vuoksi varmistetaan, että suodatin ei pettänyt meitä (suodattimet eivät koskaan valehtele!), ja näytämme luettelon "epäonnistuneista":
http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS'] Kuvakaappaus epäonnistuneiden luettelosta
Luettelo etäpalvelimen kansion versioista
On toinen tapa saada luettelo versioista. Pidän siitä jopa enemmän kuin Jenkins API:n käyttämisestä. No, koska jos sovellus rakennettiin onnistuneesti, se tarkoittaa, että se pakattiin ja sijoitettiin arkistoon sopivaan kansioon. Kuten arkisto on sovellusten työversioiden oletusvarasto. Kuten. No, kysytään häneltä, mitä versioita on varastossa. Kierrämme, grep ja awk etäkansion. Jos joku on kiinnostunut onelineristä, niin se on spoilerin alla.
Yhden rivin komento
Huomaa kaksi asiaa: välitän yhteystiedot otsikossa, enkä tarvitse kaikkia versioita kansiosta, ja valitsen vain ne, jotka on luotu kuukauden sisällä. Muokkaa komentoa todellisuutesi ja tarpeidesi mukaan:
curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )Töiden ja työn määritystiedoston määrittäminen Jenkinsissä
Selvitimme versioluettelon lähteen. Sisällytetään nyt tuloksena oleva lista tehtävään. Minulle ilmeinen ratkaisu oli lisätä vaihe sovelluksen rakennustehtävään. Vaihe, joka suoritettaisiin, jos tulos olisi "menestys".
Avaa kokoonpanotehtävän asetukset ja vieritä alas. Napsauta painikkeita: Lisää rakennusvaihe -> Ehdollinen vaihe (yksi). Valitse vaiheasetuksista ehto Tämänhetkinen rakennustila, aseta arvo MENESTYS, toiminto, joka suoritetaan, jos se onnistuu Suorita shell-komento.
Ja nyt se hauska osa. Jenkins tallentaa työmääritykset tiedostoihin. XML-muodossa. Matkan varrella http://путь-до-задания/config.xml Vastaavasti voit ladata konfigurointitiedoston, muokata sitä tarpeen mukaan ja laittaa takaisin sinne, missä sen sait.
Muista, että sovimme yllä, että luomme parametrin versioluettelolle BUILD_VERSION?
Ladataan asetustiedosto ja katsotaan sen sisään. Vain varmistaaksesi, että parametri on paikallaan ja haluttua tyyppiä.
Kuvakaappaus spoilerin alla.
Config.xml-fragmentin pitäisi näyttää samalta. Paitsi, että valinnat-elementin sisältö puuttuu vielä
Oletko varma? Siinä kaikki, kirjoitetaan skripti, joka suoritetaan, jos rakennus onnistuu.
Skripti vastaanottaa luettelon versioista, lataa määritystiedoston, kirjoittaa siihen versioluettelon haluamaasi paikkaan ja laittaa sen sitten takaisin. Joo. Oikein. Kirjoita luettelo versioista XML-muodossa siihen paikkaan, jossa versioluettelo on jo olemassa (tulee olemaan tulevaisuudessa, skriptin ensimmäisen käynnistyksen jälkeen). Tiedän, että maailmassa on edelleen kivoja säännöllisten lausekkeiden faneja. En kuulu heihin. Ole hyvä ja asenna koneeseen, jossa asetusta muokataan. Minusta näyttää siltä, että tämä ei ole niin suuri hinta, jotta vältytään XML-muokkauksesta sed:llä.
Spoilerin alla esitän koodin, joka suorittaa yllä olevan sekvenssin kokonaisuudessaan.
Kirjoita luettelo versioista etäpalvelimen kansiosta konfiguraatioon
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlJos pidät mahdollisuudesta hankkia versioita Jenkinsiltä ja olet yhtä laiska kuin minä, niin spoilerin alla on sama koodi, mutta Jenkinsin lista:
Kirjoita luettelo versioista Jenkinsistä konfiguraatioon
Pidä vain tämä mielessä: kokoonpanonimeni koostuu järjestysnumerosta ja versionumerosta, jotka on erotettu kaksoispisteellä. Vastaavasti awk katkaisee tarpeettoman osan. Muuta tätä riviä itsellesi tarpeidesi mukaan.
#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml
############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml
xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml
############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml
############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')
############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r |
while IFS= read -r line
do
xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
done
############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml
############## Приводим рабочее место в порядок
rm -f appConfig.xmlTeoriassa, jos olet testannut yllä olevien esimerkkien perusteella kirjoitettua koodia, niin käyttöönottotehtävässä pitäisi jo olla pudotusluettelo versioineen. Se on kuin kuvakaappauksessa spoilerin alla.
Oikein täytetty versioluettelo
Jos kaikki toimi, kopioi ja liitä komentosarja Suorita shell-komento ja tallenna muutokset.
Yhdistetään Cloud Shelliin
Meillä on keräilijät konteissa. Käytämme Ansiblea sovellusten toimitustyökaluna ja konfigurointien hallinnassa. Vastaavasti konttien rakentamisen yhteydessä tulee mieleen kolme vaihtoehtoa: asenna Docker Dockeriin, asenna Docker koneeseen, jossa on Ansible, tai rakenna kontteja pilvikonsoliin. Sovimme, että vaikenemme Jenkinsin laajennuksista tässä artikkelissa. Muistaa?
Päätin: no, koska pilvikonsoliin voidaan kerätä "pakkauksesta poistetut" astiat, niin miksi vaivautua? Pidä se puhtaana, eikö? Haluan kerätä Jenkins-säiliöt pilvikonsoliin ja käynnistää ne sieltä cuberiin. Lisäksi Googlen infrastruktuurissa on erittäin monipuolisia kanavia, mikä vaikuttaa suotuisasti käyttöönoton nopeuteen.
Jotta voit muodostaa yhteyden pilvikonsoliin, tarvitset kaksi asiaa: gpilvi ja käyttöoikeudet Google Cloud API VM-esiintymälle, josta tämä sama yhteys muodostetaan.
Niille, jotka suunnittelevat yhteyden muodostamista ei ollenkaan Google-pilven kautta
Google sallii interaktiivisen valtuutuksen poistamisen käytöstä palveluissaan. Näin voit muodostaa yhteyden konsoliin jopa kahvinkeittimestä, jos se on käynnissä *nix ja siinä on itse konsoli.
Jos minun on tarpeen käsitellä tätä asiaa tarkemmin tämän muistion puitteissa, kirjoita kommentteihin. Jos saamme tarpeeksi ääniä, kirjoitan tästä aiheesta päivityksen.
Helpoin tapa myöntää oikeudet on verkkokäyttöliittymän kautta.
- Pysäytä VM-ilmentymä, josta myöhemmin muodostat yhteyden pilvikonsoliin.
- Avaa Ilmentymän tiedot ja napsauta muuttaa.
- Valitse sivun alalaidasta ilmentymän käyttöoikeusalue Täysi pääsy kaikkiin pilvisovellusliittymiin.
kuvakaappaus
- Tallenna muutokset ja käynnistä ilmentymä.
Kun VM on latautunut, muodosta yhteys siihen SSH:n kautta ja varmista, että yhteys tapahtuu ilman virhettä. Käytä komentoa:
gcloud alpha cloud-shell ssh Onnistunut yhteys näyttää suunnilleen tältä
Ota käyttöön GKE:ssä
Koska pyrimme kaikin mahdollisin tavoin siirtymään kokonaan IaC:hen (Infrastucture as a Code), Docker-tiedostomme tallennetaan Gitiin. Tämä on toisaalta. Ja käyttöönotto kubernetesissa kuvataan yaml-tiedostolla, jota käyttää vain tämä tehtävä, joka on myös kuin koodi. Tämä on toiselta puolelta. Yleisesti ottaen suunnitelma on tämä:
- Otamme muuttujien arvot BUILD_VERSION ja valinnaisesti niiden muuttujien arvot, jotka välitetään ENV.
- Lataa docker-tiedosto Gitistä.
- Luo yaml käyttöönottoa varten.
- Lataamme molemmat tiedostot scp:n kautta pilvikonsoliin.
- Rakennamme sinne kontin ja työnnämme sen Container-rekisteriin
- Käytämme kuorman käyttöönottotiedostoa cuberiin.
Ollaan tarkempia. Kun aloimme puhua ENV, oletetaan sitten, että meidän on välitettävä kahden parametrin arvot: PARAM1 и PARAM2. Lisäämme heidän tehtävänsä käyttöönottoa varten, tyyppi - Merkkijonoparametri.
kuvakaappaus
Luomme yamlin yksinkertaisella uudelleenohjauksella kaiku arkistoida. Oletetaan tietysti, että sinulla on docker-tiedostossasi PARAM1 и PARAM2että kuorman nimi tulee olemaan mahtava sovellus, ja koottu säiliö, jossa on määritetty versio, sijaitsee Säilön rekisteri matkan varrella gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONMissä $BUILD_VERSION valittiin juuri avattavasta luettelosta.
Joukkueen listaus
touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo " name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo " replicas: 1" >> deploy.yaml
echo " selector:" >> deploy.yaml
echo " matchLabels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " template:" >> deploy.yaml
echo " metadata:" >> deploy.yaml
echo " labels:" >> deploy.yaml
echo " run: awesomeapp" >> deploy.yaml
echo " spec:" >> deploy.yaml
echo " containers:" >> deploy.yaml
echo " - name: awesomeapp" >> deploy.yaml
echo " image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo " env:" >> deploy.yaml
echo " - name: PARAM1" >> deploy.yaml
echo " value: $PARAM1" >> deploy.yaml
echo " - name: PARAM2" >> deploy.yaml
echo " value: $PARAM2" >> deploy.yamlJenkinsin agentti liittämisen jälkeen gcloud alpha cloud-shell ssh interaktiivinen tila ei ole käytettävissä, joten lähetämme komennot pilvikonsoliin parametrin avulla --komento.
Puhdistamme pilvikonsolin kotikansion vanhasta docker-tiedostosta:
gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"Aseta juuri ladattu docker-tiedosto pilvikonsolin kotikansioon käyttämällä scp:tä:
gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~Keräämme, merkitsemme ja siirrämme säilön Container-rekisteriin:
gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
Teemme samoin käyttöönottotiedoston kanssa. Huomaa, että alla olevat komennot käyttävät kuvitteellisia nimiä klusterille, jossa käyttöönotto tapahtuu (awsm-klusteri) ja projektin nimi (mahtava projekti), jossa klusteri sijaitsee.
gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project &&
kubectl apply -f deploy.yaml"Suoritamme tehtävän, avaamme konsolin ulostulon ja toivomme näkevämme kontin onnistuneen kokoonpanon.
kuvakaappaus
Ja sitten kootun kontin onnistunut käyttöönotto
kuvakaappaus
Olen tietoisesti jättänyt asetuksen huomioimatta Sisääntulo. Yhdestä yksinkertaisesta syystä: kun olet määrittänyt sen työmäärä tietyllä nimellä, se pysyy toiminnassa riippumatta siitä, kuinka monta käyttöönottoa tällä nimellä suoritat. No, yleisesti ottaen tämä on hieman historian ulottumattomissa.
Päätelmien sijasta
Kaikkia yllä olevia vaiheita ei luultavasti olisi voitu tehdä, vaan asentaa vain jonkin laajennuksen Jenkinsille, heidän muuulionilleen. Mutta jostain syystä en pidä plugineista. Tarkemmin sanottuna turvaudun niihin vain epätoivosta.
Ja haluan vain poimia minulle uuden aiheen. Yllä oleva teksti on myös tapa jakaa havainnot, jotka tein ratkaisin heti alussa kuvattua ongelmaa. Jaa niiden kanssa, jotka hänen tavoin eivät ole ollenkaan hirveä susi devopsissa. Jos löydöistäni on apua ainakin jollekin, olen iloinen.
Lähde: will.com