Slack-virheraportti GitHub-korjaukseen
Kuvaile virhettä selkeällä kielellä Slack:ssä. Okou kirjoittaa GitHub-ongelman ja määrittää sen, ja kun syy on yhdessä komponentissa, se avaa pull-pyynnön korjauksella ja regressiotestillä tarkistettavaksi.
Mitä Okou tarjoaa: Slack-viestistä korjaukseen tarkistuksessa
Todellinen keskustelu vm0-tiimin kanavalta #bug-report, tallennettuna sellaisenaan. Tiimikaveri liitti asiakkaan raportin ja pyysi korjausta. Neljä minuuttia myöhemmin Okou oli tehnyt GitHub-ongelman diagnoosin kanssa. Neljätoista minuuttia ensimmäisen viestin jälkeen se oli avannut pull requestin ja julkaissut esikatselulinkin. Alla ovat molemmat tallenteet: keskustelu, josta se alkoi, ja pull request, jonka Okou kirjoitti. Ne ovat julkisia, joten voit lukea ongelman, eron ja arvostelun itse.
Mitä ketjussa tapahtui
Tiimikaveri raportoi asiakkaan PWA-asetteluvirheestä kanavalla #bug-report ja liitti kuvakaappaukset. Okou luki keskustelun, jäljitti sen yläpalkkiin, joka renderöitiin ilman iOS:n turva-alueen sisennystä, ja teki virheilmoituksen #11708 tunnisteineen ja perusteluineen. Kun keskustelussa kysyttiin korjausta, Okou muutti yhden tiedoston (mobiilin yläpalkin minimikorkeus ja turva-alueen täyte), avasi pull requestin #11709 esikatselulinkin kanssa ja pysähtyi siihen. Henkilö tarkisti ja yhdisti sen.
- Viesti arkistoituun ongelmaan
- 4 minongelma #11708, merkitty bugiksi ja PWA:ksi
- Viesti pull-pyyntöön
- 14 minPR #11709 esikatselulinkin kanssa
- Korjauksen muuttamat tiedostot
- 1henkilön yhdistämä, ei Okou:n
Mitä tarkoittaa GitHub-ongelman luominen Slack:stä?
GitHub-ongelman luominen Slack:stä tarkoittaa, että keskustelussa kuvattu virhe muutetaan asianmukaisesti jäsennellyksi ongelmaksi arkistossasi ilman, että kukaan poistuu keskustelusta kirjoittaakseen sen uudelleen. Vaikein osa ei koskaan ollut API-kutsu; se on selkeän otsikon kirjoittaminen, toistovaiheiden erottaminen odotetusta käyttäytymisestä, tunnisteiden valitseminen, prioriteetin asettaminen ja oikean omistajan löytäminen. Okou tekee tämän työn. Se lukee Slack-viestin ja sitä ympäröivät vastaukset, kirjoittaa ongelman rungon, soveltaa tunnisteita ja prioriteetin, jonka se voi perustella, ratkaisee vastuuhenkilön yhdistämällä Slack-näyttönimen GitHub-tunnukseen ja lähettää ongelman linkin takaisin samaan keskusteluun, jotta raportoija voi tarkistaa sen yhdellä silmäyksellä.
Miksi virheraportit kuolevat Slack-ketjuissa
Joku huomaa virheen demon aikana, tai asiakas kirjoittaa viestin lauantaina. Vanha polku on pitkä: avaa GitHub, etsi arkisto, kirjoita muotoiltu ongelma, määritä joku vastuuseen ja odota, että kyseinen henkilö ottaa sen käsiteltäväkseen, lukee koodin ja kirjoittaa korjauksen. Kymmenen minuutin muutos muuttuu usean päivän edestakaiseksi matkaksi kolmen ihmisen välillä, ja puolet raporteista ei koskaan pääse ulos keskustelusta. Sen sijaan kuvailet sen Slack:ssä. Okou kirjaa ongelman toistovaiheineen, tunnisteineen ja omistajineen, ja jos syy on tiedossa, se avaa pull requestin korjauksella ja testillä. Sinä tarkistat ja julkaiset.
Miten Okou luo GitHub-asian Slack:stä
Vaihe 1: Yhdistä työkalusi
Vaihe 2: Kysy Okou
Vaihe 3: Vie se pidemmälle
Slack- ja GitHub-integraatiot työnkulun takana
Tämä on Slack GitHub -integraatio, jossa on agentti keskellä: Okou lukee keskustelun Slack:ssä ja kirjoittaa tiedon GitHub:ään. Jokainen liitin myönnetään erikseen ja rajataan siihen, mitä työnkulku todella käyttää, joten kanavan lukeminen ei koskaan tarkoita kirjoitusoikeutta arkistoihisi.
Slack-integraatio: keskustelu, jonka Okou lukee
PakollinenOkou lukee viestin, johon osoitat sen, ja sitä ympäröivät vastaukset, joten kolme viestiä myöhemmin saapunut konteksti päätyy silti ongelmaan. Se poimii liitetyt kuvakaappaukset ja siirtää ne, lukee raportoijan näyttönimen määrittääkseen vastuuhenkilön ja säilyttää viestin pysyvän linkin, jotta jokainen ongelma linkittyy takaisin siihen, mistä raportti alkoi. Kirjoittaminen on vain yksi asia: vastaus samaan ketjuun ongelmanumeron ja linkin kanssa. Okou ei julkaise muille kanaville, lähetä suoria viestejä tai muokkaa kenenkään viestejä.
GitHub-integraatio: ongelma, jonka Okou tiedostoi
PakollinenOkou luo ongelman nimeämääsi arkistoon otsikolla, joka on kirjoitettu raportista eikä raa'an viestin kopiona, kuvauksella, toistovaiheilla, odotetulla käyttäytymisellä ja vaikutusalueella, kun ketju nimeää sellaisen. Se soveltaa määrittämiäsi tunnisteita tai päättelee ne sanamuodosta, asettaa selittämänsä prioriteetin ja määrittää omistajan. Ennen arkistointia se etsii avoimista ongelmista samaa oiretta ja kommentoi olemassa olevaa, kun se löytää vastaavuuden. Kun se voi myös korjata virheen, se työntää haaran ja avaa pull-pyynnön, joka sulkee ongelman ja pyytää tarkistusta. Kirjoitusoikeus on rajattu myöntämiisi arkistoihin, ja se on koko pinta: ongelmat, kommentit ja tarkistettavaksi avatut pull-pyynnöt. Okou ei yhdistä, pakota työntämään tai kosketa arkiston asetuksia.
Okou vs. GitHub-sovellus Slack:lle vs. automaatiorakentaja
Bugin saaminen Slack-viestistä GitHub:iin koostuu kolmesta osasta: raportin sieppaamisesta, käyttökelpoisen ongelman kirjoittamisesta ja sen reitittämisestä omistajalle. Olemassa olevat vaihtoehdot ratkaisevat kukin yhden niistä.
GitHub-sovellus Slack:lle
Kirjoittamalla /github avautuu valintaikkuna, johon täytät itse otsikon, tekstin, tunnisteet ja vastuuhenkilön. Se säästää matkan selaimeen, mutta sinä olet edelleen se, joka kirjoittaa ongelman, ja lomake keskellä keskustelua on juuri se kitka, joka saa ihmiset sanomaan "arkistoin sen myöhemmin".
Automaation rakentaja
Kooditon rakentaja voi kopioida Slack-viestin uuteen ongelmaan laukaisimen perusteella. Se kopioi raa'an viestin, joten ongelma perii kaiken, mitä raportoija sattui kirjoittamaan, ja tunnisteiden, prioriteetin, määrityksen ja kaksoiskappaleiden säännöt ovat sellaisia, jotka sinun on määriteltävä ja ylläpidettävä kanavakohtaisesti.
Okou:n Slack-GitHub-työnkulku
Okou lukee keskustelun ja kirjoittaa ongelman: todellisen otsikon, toistovaiheet erotettuna odotetusta käyttäytymisestä, perustellut tunnisteet ja prioriteetin sekä määrätyn henkilön, joka on sovitettu raportoijan näyttönimestä. Kun syy rajoittuu yhteen komponenttiin, se jatkaa ja avaa pull-pyynnön korjauksella ja regressiotestillä, linkitettynä ongelmaan ja odottaen tarkistustasi. Se tarkistaa ensin avoimet ongelmat ja kommentoi kaksoiskappaletta sen sijaan, että arkistoisi sellaisen, ja se vastaa keskusteluun linkillä.
Vinkkejä parempiin tuloksiin
Usein kysytyt kysymykset
Miten luot GitHub-ongelman Slack-viestistä?
Yhdistä Slack ja GitHub Okou:een, kuvaile sitten virhe kanavalla ja mainitse Okou. Se lukee viestin ja ympäröivät vastaukset, kirjoittaa ongelman otsikolla, toistovaiheilla, odotetulla käyttäytymisellä, tunnisteilla ja prioriteetilla, luo sen nimeämääsi arkistoon, määrittää omistajan ja vastaa ketjuun ongelmanumerolla ja linkillä. Sinun ei tarvitse täyttää lomaketta.
Miten tämä eroaa GitHub-sovelluksesta Slack:lle?
GitHub-sovellus antaa sinulle valintaikkunan täytettäväksi: kirjoitat edelleen otsikon, tekstin, tunnisteet ja vastuuhenkilön. Okou kirjoittaa ne keskustelusta, tarkistaa olemassa olevan ongelman samalla oireella ennen arkistointia ja voi ajaa koko kanavan läpi aikataulun mukaisesti yhden viestin sijaan.
Kirjaaako Okou vain ongelman, vai voiko se korjata virheen?
Molemmat, ja se kertoo sinulle, kumman se teki ja miksi. Okou tekee aina virheilmoituksen. Kun ketju tai koodi osoittaa yhteen komponenttiin, odotettu käyttäytyminen on yksiselitteinen ja epäonnistunut testi voidaan kirjoittaa ensin, se avaa myös pull requestin korjauksen ja kyseisen testin kanssa, linkittää sen virheilmoitukseen ja pyytää tarkistusta. Jaetut apuohjelmat, suunnittelutokenit ja kaikki, mikä vaatii tuotepäätöksen, arkistoidaan eikä muuteta. Okou ei koskaan yhdistä; jokainen korjaus saapuu pull requestina, jonka tarkistat.
Voiko Okou määrittää ongelman oikealle henkilölle automaattisesti?
Kyllä. Okou vastaa mainitsemaasi nimeä tai raportoijan Slack-näyttönimeä arkiston GitHub-tunnuksiin ja määrittää asian. Nimeämällä toimeksisaajan viestissäsi on luotettavin tapa; kun ketään ei nimetä, Okou palaa sen alueen omistajaan, johon ketju osoittaa, ja kertoo asiassa, miten se päätti.
Miten Okou välttää GitHub-ongelmien kaksoiskappaleiden kirjaamisen?
Ennen kuin Okou luo mitään, se etsii avoimista ongelmista samankaltaisia oireita, vaikutusalueita ja sanamuotoja. Kun se löytää vastaavuuden, se lisää uuden Slack-ketjun kommenttina kyseiseen ongelmaan, raportoijan ja aikaleiman kera, ja vastaa Slack:ssä olemassa olevalla ongelmalinkillä avaamatta toista.
Mitä tapahtuu, kun virheraportissa ei ole toistovaiheita?
Okou jättää silti asian, jotta raportti ei katoa, merkitsee sen vaativaksi toistovaiheita ja vastaa Slack-ketjussa pyytäen niitä raportoijalta. Vastaus ilmestyy sitten ketjuun, joka on jo linkitetty asiasta.
Voiko Okou kirjata virheitä koko kanavalta aikataulun mukaisesti?
Kyllä. Osoita Okou yhteen tai useampaan kanavaan ja anna sille aikataulu, esimerkiksi joka perjantai klo 16. Se lukee viikon viestit, luo ongelman jokaisesta virhettä kuvaavasta viestistä, kommentoi kaksoiskappaleita, ohittaa ominaisuuspyynnöt ja kysymykset ja raportoi tekemästään.
Toimiiko tämä Linear:n tai Jiran kanssa GitHub:n sijaan?
Sama työnkulun muoto pätee kaikkiin seurantajärjestelmiin, joihin Okou on yhdistetty; tämä sivu käsittelee GitHub-polkua, joka käyttää GitHub-liitintä. Linear on yhdistetty samalla tavalla, ja nimeät seurantajärjestelmän ohjeessa.
Tallenna seuraava virheesi poistumatta Slack:stä
Yhdistä Slack ja GitHub, kuvaile virhettä samalla tavalla kuin tekisit tiimikaverille, ja anna Okou:n kirjoittaa ongelma ja määrätä se. Kun syy on rajattu, pull request odottaa sinua myös.
