Pipa za CI / CD za haraka na rahisi na toleo la semantic kwa lugha yoyote au chombo. Kuchapisha toleo jipya la chombo kinapaswa kuwa laini. Hakuna sherehe, hakuna mipango ya mikutano, wala hata mjadala. Inapaswa kuwa wazi, bila juhudi, ya kuaminika, na hata ya habari - zaidi kuhusu hilo baadaye. Hata hivyo, kama mshauri wa programu ambaye husaidia timu kutekeleza ufumbuzi wa DevOps, mara nyingi ninaona kwamba hii sio kesi. Nini ninaona ni tofauti sana katika ubora, hivyo badala ya kukuambia kile ninachokipenda, hebu tuangalie jinsi ninapenda kuunda miundombinu yangu ili kuweka hifadhi mpya haraka na kwa urahisi. Ili kuelewa mtazamo wangu, ningependa kushiriki jinsi maoni yangu juu ya mada imebadilika kwa miaka. Kwa sasa, ninatumia mchakato ambao unahusisha kutengeneza "LEGO blocks" ya kazi za modular na maboresho madogo, kama vile mabadiliko ya vigezo. Kwa mfano, mchakato wa kujenga kwa maktaba ya Rust X pengine ni sawa na maktaba ya Rust Y, na foo ya seva ya Node pengine ni sawa na bar ya seva ya Node. Kwa miaka, nilijaribu kukusanya vipengele vya chanzo cha wazi ili kufikia hili, lakini sikuwahi kupata mchanganyiko sahihi kabisa. Lakini kwanza ... Najua versioning na kuchapisha sio mada ya kusisimua zaidi; hata hivyo, ni tatizo ambalo kila mradi unakabiliwa, hata wakati vibe-coded (hakika hasa!). Kazi sahihi itafanya mradi wako kuonekana zaidi wa kitaaluma na kuwasiliana na mabadiliko kwa watumiaji wake. Hili huunda imani zaidi katika miradi yako kwa kusaidia watengenezaji kuelewa na kuchukua mabadiliko mapya kwa njia ya wazi na ya kudumu. Katika mwanzo ... Nyuma katika mwanzo wa kazi yangu ya uhandisi wa programu, machapisho yalikuwa tukio kubwa kabisa. Walikuwa bidhaa ya marudio, iliyopatikana kupitia mfululizo wa sprints, iliyopangwa, kwa uwezo wa kila mtu, katika mfululizo wa mikutano ya mipango ambapo upungufu ulifutwa, na kazi ambazo zilikuwa na thamani zilichaguliwa. Tunajaribu kuandika maelezo ya mpango, na kuhesabu idadi ya Fibonacci au ukubwa wa T-Shirt, au katika kesi mbaya zaidi, siku kadhaa. Uwasilishaji ulikuwa kiwango cha juu cha mchakato huu. Uwasilishaji wa uwasilishaji, uliotumwa kwa watumiaji halisi. Kama kiwango cha juu cha mchakato huu, na viwango vya juu vya kupata haki, uwasilishaji ulikuwa wakati wa hisia. ya kusisimua? ya kutisha? Labda wachache ambao umechochea wamepata moyo wako wa kushindana kama wao kuweka mashine katika harakati. Pia kuna maelezo na drama ya kuamua idadi ya toleo. Je, hii ni toleo kubwa? toleo jipya jipya?? Wakati mwingine masoko yalisema toleo la ... 2.0! Katika hatua hii ya kazi yangu, kwa kiasi kikubwa si maoni yangu ambayo yalikuwa na umuhimu juu ya mada hii ya idadi ya toleo, na kuangalia nyuma, pengine haipaswi kuwa ya mtu yeyote (utaona kile ninafikiri baadaye). Sikuwa na jukumu la kutolewa mwanzoni... Hata hivyo... hii haitakuwa ya kudumu. kwa chanzo cha wazi Wakati fulani katika kazi yangu, nilianza kuwa na nia ya kuchangia kwa chanzo cha wazi. Kwa ujumla, katika fomu ya modules npm, kama nilikuwa na ujuzi mkubwa wa Node wakati huo. Ilikuwa ni mzunguko wangu kuwajibika kwa ajili ya kuachiliwa. Siwezi kukumbuka jinsi, labda kwa njia ya gazeti fulani au labda sehemu ya mkutano wa NYC NodeJS ambayo Matt Walters na mimi tulitumia kuendesha pamoja - nilikuja kwenye maktaba. Semantic Release ilitumia kanuni, ambayo nilikuwa nimepata kama mtengenezaji wa wavuti, ya kutenganisha wasiwasi kulingana na semantics. semantic-release Kabla ya kuondoka na kuanza kutumia semantic-release, kuna mipaka fulani niliyokutana nayo ... Na nitafikia wale katika muda mfupi. Kwanza, kwa kiwango cha juu, wazo la msingi kwamba semantic-release ilitangaza ilikuwa kwamba utakuwa kufuata muundo maalum kwa ujumbe wako wa commit, na kulingana na ujumbe, toleo linaweza kuhesabiwa. Inazungumzia kuondoa hisia kutoka kwa machapisho, kuifanya kuwa robotic, kulingana na kile kilichobadilika. Ikiwa kulikuwa na toleo jipya la toleo kubwa - v2 kwa v3, kwa mfano, hiyo inamaanisha kulikuwa na mabadiliko makubwa. Ili kuelezea hili katika ujumbe wako wa commit, ungependa ndani ya mwili wa mwili. BREAKING CHANGE: feat: revamp user auth flow BREAKING CHANGE: Per Chad's "game-changer" vision in the 3am Slack rant, we've ditched the old auth system for a blockchain-based solution because "passwords are so 2024." Update your clients or enjoy the 500 errors! Mabadiliko madogo ya toleo, kama vile v2.0.0 hadi v2.1.0, yalimaanisha kuwa kipengele kipya kiliongezwa. feat: add dark mode toggle Per the 47-comment thread in the "urgent" ticket, users can now save their retinas. Dark mode added, but brace for the inevitable "make it darker" feedback. Toleo la patch lilionyesha ufumbuzi, au refactors, au kimsingi kitu kingine chochote ambacho kinapaswa kusababisha toleo jipya. fix: revert "fix" by AI that skipped the breaking tests to avoid the failure Na hatimaye, baadhi ya ahadi haipaswi kuchochea kutolewa kabisa. "Sherehe" kama zilivyoonyeshwa kwangu. chore: update release pipeline version from v3.1.0 to v3.1.1 Ujumbe huu maalum wa ujumbe wa commit ulijulikana kama Unaweza kuangalia ukurasa wao kwa spec kamili, lakini nilitaka kushiriki kiini cha hiyo. Tume ya kawaida Zaidi ya hayo, habari hii iliyohifadhiwa katika commits inaweza pia kuonekana kama kumbukumbu ya mabadiliko - kama vile kuonyesha mabadiliko ya kuanguka. What's new in v2.0.0 * feat: remove deprecated API BREAKING CHANGE: the FooBar API that was deprecated. To upgrade, you can use the new BazBar API. Hivyo, kwa muda, semantic-kuchapisha ilikuwa nzuri kwangu. Kwa miradi ya Node, bado ni ... Hata hivyo... Kwa ajili ya DevOps Daima nilikuwa na nia ya wazo la jinsi ya kujenga mifumo ya usambazaji inayoweza kupanua, na hivyo ilikuwa kitu nilichotafuta kwa muda mrefu katika kazi yangu. hadithi ndefu, hatimaye nilijifunza jinsi ya kufanya vizuri, lakini nilikuwa na tatizo jipya: jinsi ya kutumia vipande vyote. Hizi hazikuwa moduli za npm; zilikuwa maombi, huduma, databases, na mikono! Nilipenda urahisi wa uwasilishaji wa semantic, lakini ilifanya kazi vizuri tu kwa miradi ya Node.js. Bila shaka, unaweza, na nilifanya mara chache, kuongeza faili kwa miradi yasiyo ya node, lakini hiyo ilikuwa mbaya na ya hacky kwa wakati mzuri. package.json Karibu wakati huu, nilipata ushiriki mkubwa katika DevOps, wakati wa enzi ya Jenkins, kama Docker alikuwa anaanza kupata traction. Nilijifunza kuandika pipelines na Jenkins na kutumia kila kitu na Docker Swarm! Safari yangu ya mwanzo ya DevOps na ufunuo wa Docker kwa utekelezaji. Mimi pia nilikuwa kukubali maendeleo ya msingi ya trunk wakati huo, na kujitolea kutawala. makala yangu ya hivi karibuni na bado inahusiana na sahihi ya Mwongozo wa Kuingia na Maendeleo ya msingi ya Trunk inaelezea kwa nini na jinsi ya hiyo ikiwa una nia. Mimi pia nilikuwa kukubali maendeleo ya msingi ya trunk wakati huo, na kujitolea kutawala. makala yangu ya hivi karibuni na bado inahusiana na sahihi ya Mwongozo wa Kuingia na Maendeleo ya msingi ya Trunk inaelezea kwa nini na jinsi ya hiyo ikiwa una nia. Mimi daima alitaka miradi hizi niliyofanya kazi na kuwa versioned na kuchapishwa kama miradi semantic-kuchapisha walikuwa, lakini sikuwahi kupata suluhisho kwamba kazi pia. Haikuwa kitu muhimu zaidi kwenye orodha yangu, hivyo kwa ujumla niliita vizuri sana na niliishi na makosa. Kwa muda, kama mshauri wa DevOps, nimewasiliana na kutolewa miradi mbalimbali katika lugha nyingi na miundombinu, na kila moja inahitaji versioning, kutolewa, na changelogs. Maumivu mengine ya kichwa niliyokutana mara nyingi yalikuwa pipa kubwa, za monolithic. Kutoka wakati wa Jenkins, ninaweza kupata, hii ni jinsi nilivyokuwa nikisoma pipelines pia. Ningependa kujaribu kuwa na mtiririko wote wa kutolewa katika mfululizo mkubwa wa hatua, kuanzia na kushinikiza kwa kuu. Ikiwa unachukuliwa kwa kuu, udhibiti wa ubora wa aina mbalimbali utakuwa unaendeshwa, na toleo jipya litatengenezwa, kuchapishwa, na kuchapishwa. Hii si mbaya kwa mwenyewe na pia pengine ni "bora ya kutosha" katika kesi nyingi; hata hivyo, kama mshauri wa DevOps, ninahitaji kufanya hivyo mara kwa mara. Kuondoa mambo kwa vipande vidogo, zaidi vya modular inaruhusu vipande hivi kutumikia miradi zaidi. , wazo ambalo linatokana na kuchukua falsafa za UNIX. Ufafanuzi wa mawazo Kwa mfano, Node Quality pipeline inaweza kuwa sawa katika kila mradi wa Node, ikimaanisha unafuata makubaliano ya kiwango cha script ya npm, na hivyo pipeline ya kawaida ya kuendesha linting, kujenga, na majaribio ya kipengele inaweza kushirikiana zaidi, ikiwa sio wote, miradi ya Node.js. na vinginevyo, na sehemu ya maandishi ya faili kuamua nini kinatokea wakati huo huo Utaratibu wa uendeshaji umefanyika. npm run lint --if-present package.json lint Pipelines ya kiwango cha juu kwa ajili ya toleo na kutolewa Katika ngazi ya juu, kila mradi unaohitajika kuchapishwa utachapishwa kwanza na nambari mpya ya toleo. Kisha, toleo linaweza kuundwa ambayo inahusishwa na nambari hiyo ya toleo, na vitu vilitengenezwa kama sehemu ya vifaa vya kuhusika. Mimi kutumia GitHub Action mara nyingi zaidi, kwa sababu nadhani pipelines ni bidhaa, na ni rahisi kuanza na. Nimekuwa kutumia wengi, lakini wote ni kimsingi sawa - kufanya mfululizo wa hatua na safu ya kushiriki. Mabadiliko yenyewe, ikiwa tunataja kiwango cha maombi ya kawaida yanayohusiana na ongezeko la toleo la semantic, sio jambo la lugha maalum. Haihusiani na maudhui ya nambari; badala yake, inahusiana na historia ya matoleo na maombi. Kwa muda mrefu, niliunganisha machapisho kwa matoleo, nadhani walikuwa sehemu ya kitu kimoja, wakati katika ukweli, wao ni viungo viwili tofauti vilivyounganishwa pamoja. Kuanguka kwao tofauti ilifanya sehemu ya toleo la pipeline sehemu yake mwenyewe ya modular, ambayo kisha ilisababisha ujenzi wa toleo hilo na kuchapishwa baadaye. Kwa kila mradi, katika Hatua za GitHub, nina pipelines mbili: On commit to the trunk branch, version, and tag When a commit occurs in the trunk branch (usually or ), trigger a pipeline that runs quality checks, and, if they pass, calculates a new version number. It then creates and pushes a tag with that new version number. We can also use this opportunity to update that version number in the code base if necessary, and generate a change log from the commit data that was used to calculate the new version number. main master When a tag is created, build new versions and release them. This step is simplified by the previous step of doing the version bump. Everything’s already been bumped to the new version. We can just run build and release using the tag as the base. Kama nilivyosema hapo awali, baada ya kujaribu mara nyingi kuunganisha vipengele vya chanzo cha wazi kutoka kwenye GitHub Action Marketplace, hatimaye niliacha na kuandika chombo changu mwenyewe ambacho kinakabiliana na hatua ya kwanza. Maelezo ya vnext ya baadaye vnext ni chombo cha haraka cha Rust CLI ambacho hutumia ujumbe wa kawaida wa kuhamisha ili kuhesabu toleo lako la semantic ijayo, automatising kubwa, ndogo, au patch bumps kwa machapisho yaliyotengenezwa. Hapa ni jinsi ya kutumia. NEXT_VERSION=v`vnext` vnext --changelog > CHANGELOG.md Nadhani ni rahisi sana!Nendeni mkaweke alama yako mwenyewe. Ni msingi wote juu ya historia ya git ya mradi. Haijalishi lugha au chombo unachotolewa; mchakato wa toleo ni sawa kabisa. Kupata toleo jipya, kuboresha kwa faili fulani, kuunda changelog, tag, na push. Tofauti pekee ni faili ambazo zinahitaji kuboreshwa - hii inahesabiwa katika mtiririko wa kazi nitakuja kushiriki kwa wakati mmoja. ni haraka na rahisi kufunga kupitia - ya Mara baada ya kuhifadhi, unaweza kuendesha: vnext ubi Mtandao wa Universal Binary Installer ubi --project unbounded-tech/vnext Pia nimeunda mchakato wa kazi wa GitHub Action ambao unaweza kuita, ambayo inashughulikia maelezo hayo yote. Hapa ni jinsi ya kutumia mchakato wa kazi ulioshirikiwa: name: On Push Main, Version and Tag on: push: branches: - main - master permissions: packages: write contents: write jobs: version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1 with: useDeployKey: true changelog: true Wengi wa miradi pia watahitaji kuunda jinsi na faili gani za kuboresha na idadi ya toleo jipya. kwa sasa , Mstari wa chini: Roho inawakilisha thamani ( na ya ) na chaguzi chache za lugha maalum. vnext yqPatches regexPatches Chaguo la lugha maalum ni rahisi zaidi kutumia. Kwa mfano, ya matumizi ya kurekebisha faili za mchakato wa mradi. with.node true npm Jinsi ya kutumia chombo kurekebisha mashamba maalum katika faili ya YAML. Ninatumia mara nyingi hii kwa update idadi ya toleo katika chati za Helm: yqPatches yq version-and-tag: uses: unbounded-tech/workflow-vnext-tag/.github/workflows/workflow.yaml@v1.13.0 secrets: GH_PAT: ${{ secrets.YOUR_ORG_SECRET_PAT }} with: usePAT: true changelog: true yqPatches: | patches: - filePath: helm/values.yaml selector: .image.tag valuePrefix: "v" - filePath: helm/Chart.yaml selector: .version valuePrefix: "v" Pia nimechukua fursa hii ya kushiriki jinsi ya kutumia Token ya Upatikanaji wa Kibinafsi badala ya Key ya Uhamisho. Pia nimechukua fursa hii ya kushiriki jinsi ya kutumia Token ya Upatikanaji wa Kibinafsi badala ya Key ya Uhamisho. matumizi ya kutafuta na kubadilisha mstari na namba ya toleo jipya iliyowekwa. Kwa mfano: regexPatches sed regexPatches: | patches: - filePath: package/composition.yaml regex: /ghcr.io/org-name/package-name:(.*)/g valuePrefix: ghcr.io/org-name/package-name:v - filePath: README.md regex: /Current version: v[0-9]+\.[0-9]+\.[0-9]+/g valuePrefix: Current version: v Unaweza pia kutumia mchanganyiko wa chaguzi. Ufafanuzi juu ya shughuli za GitHub Wakati wa kuendesha hatua kwenye GitHub Action, kwa default, mfanyakazi huunda token ya muda mfupi ya kuthibitisha GitHub. Token hii ina ruhusa ya kufanya kazi chache za msingi; hata hivyo, haiwezi kuruhusiwa kuchochea pipelines nyingine. Lakini hatua yetu inayofuata baada ya alama ya toleo jipya ilikuwa kuchochea pipeline nyingine na alama hiyo! Usiogope, hii ni kwa ajili ya kubuni - tu hatua ya GitHub ili kuzuia kutokuwepo kwa makusudi kwa kundi la washindani. Unaweza kufanya hivyo, lakini unahitaji kuwa na nia kuhusu hilo. Kuna njia kadhaa za kuwa na nia kuhusu hilo - tayari nimeonyesha mfano wa mbili: Kutumia kifungo cha kupanua na hatua zinazohusiana na GitHub Secret Kutumia Token ya Upatikanaji wa kibinafsi kama siri ya hatua za GitHub Kujenga Maombi ya GitHub (kwa nadharia - Sikuwa na haja ya chaguo hili) Kutumia Token ya Upatikanaji wa kibinafsi ni rahisi ikiwa wewe ni mteja wa kulipa katika mazingira ya GitHub, kama siri za shirika zinapatikana. Katika ngazi ya bure, hii sio chaguo, hivyo nitakuonyesha jinsi ya kuanzisha kifungo cha kupitisha badala yake. Kwa kweli, nilifanya iwe rahisi sana kwa kujenga katika CLI. Ni chaguo kubwa, kwa sababu wakati uliowekwa kwa njia hii, hakuna binadamu anahitaji kujua, na inaweza kurekebishwa kwa urahisi kwa kurekebisha amri hiyo. vnext Kwa kila hifadhi unayotaka kuunda kuachiliwa na kifungo cha kutumika, katika orodha ya mradi ... vnext Kwanza, kupata token ya auth kwa kutumia na ruhusa ya kusimamia vifungo: gh gh auth refresh -h github.com -s admin:public_key -s admin:ssh_signing_key export GITHUB_TOKEN=$(gh auth token) Na kisha kuondoka: vnext generate-deploy-key Unaweza kujiuliza, hii haiwezi kwenda kwenye pipeline yenyewe? Kwa bahati mbaya, siwezi kupata njia ya kuchangia hatua hii katika vitendo vya Github bila kujenga Token ya Upatikanaji wa kibinafsi, kama token ya default haiwezi kubadilisha siri. Hii inashinda pupose ya kutumia Key ya Kuendesha badala ya katika ngazi ya bure, kama unahitaji kuunda katika kila repo. Hii inahitaji aina fulani ya usimamizi wa siri ili iwe rahisi, na hivyo inafanya kazi zaidi kuliko kutumia kifungo cha kupitisha. Unaweza kujiuliza, hii haiwezi kwenda kwenye pipeline yenyewe? Kwa bahati mbaya, siwezi kupata njia ya kuchangia hatua hii katika vitendo vya Github bila kujenga Token ya Upatikanaji wa kibinafsi, kama token ya default haiwezi kubadilisha siri. Hii inashinda pupose ya kutumia Key ya Kuendesha badala ya katika ngazi ya bure, kama unahitaji kuunda katika kila repo. Hii inahitaji aina fulani ya usimamizi wa siri ili iwe rahisi, na hivyo inafanya kazi zaidi kuliko kutumia kifungo cha kupitisha. Pamoja na Key yako ya Usambazaji, au Token ya Upatikanaji wa Kibinafsi (PAT), katika nafasi, na kazi ya toleo la toleo la toleo la toleo la toleo la toleo la toleo la toleo la toleo la toleo la toleo la toleo la toleo, hatua inayofuata ni kutolewa! Hii itabadilika kwa mradi mmoja, lakini wote hutokana na toleo lililojulikana kutoka hatua iliyopita. name: On Version Tag, Trigger GitHub Release on: push: tags: - 'v*.*.*' permissions: contents: write jobs: release: uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} Au, kama ni mradi wa Rust, labda kitu kama hiki: name: On Version Tagged, Build and Publish Rust Binaries on: push: tags: - "v*.*.*" permissions: contents: write jobs: build-and-release: uses: unbounded-tech/workflows-rust/.github/workflows/release.yaml@v1 with: binary_name: ${{ github.event.repository.name }} build_args: "--release --features vendored" Au ikiwa ilikuwa programu na Dockerfile, na ufafanuzi wa rasilimali za k8s kwa utekelezaji wa Gitops, labda kitu kama hiki: name: promote on: push: tags: - v*.*.* permissions: contents: write packages: write issues: write pull-requests: write jobs: publish: uses: unbounded-tech/workflows-containers/.github/workflows/publish.yaml@v1.1.1 release: needs: publish uses: unbounded-tech/workflow-simple-release/.github/workflows/workflow.yaml@v1 with: tag: ${{ github.ref_name }} name: ${{ github.ref_name }} promote: needs: release uses: unbounded-tech/workflows-gitops/.github/workflows/helm-promote.yaml@v1 secrets: GH_PAT: ${{ secrets.GH_PAT }} with: environment_repository: your-org/staging-env path: .gitops/deploy project: staging Kumbuka: Kichwa cha kupitisha haiwezi kuhamisha kwenye repo nyingine, kama vile katika hatua ya kukuza gitops, hivyo unaweza kuzingatia kutumia PAT kila mahali kwa repo hii. Ikiwa una kazi nyingi kama hii, kuboresha kwa org ya kulipwa inaweza kuwa na thamani kwa siri za shirika badala ya kuunda repo kila mmoja peke yake. Kumbuka: Kichwa cha kupitisha haiwezi kuhamisha kwenye repo nyingine, kama vile katika hatua ya kukuza gitops, hivyo unaweza kuzingatia kutumia PAT kila mahali kwa repo hii. Ikiwa una kazi nyingi kama hii, kuboresha kwa org ya kulipwa inaweza kuwa na thamani kwa siri za shirika badala ya kuunda repo kila mmoja peke yake. Kwa ujumla, kila toleo ni mchanganyiko wa baadhi ya modules hizi sawa, ambazo zinafanya mambo sawa lakini kwa zana zao maalum au lugha. Kwa kawaida, mashirika angalau kujaribu kufuata mifano mingi ya moja kwa moja katika maombi na huduma ambazo hutoa, na hivyo kuvunja mtiririko wa kazi katika sehemu za modular zilizoshirikiwa inaruhusu watengenezaji tu kuiga na kuingiza ladha yao ya wito huu wa mtiririko wa kazi zilizoshirikiwa kwa kila mradi wa aina hiyo. Kuanzishwa kwa Changelogs Unaweza kuona jinsi ya kuangalia juu ya nilitaka kurudi nyuma kwa hilo, kwa kuwa ni sehemu muhimu ya mchakato wa kuchapisha. changelog ni jinsi gani unaweza kuwasiliana njia ambazo mradi wako umebadilika kwa watengenezaji wengine. with.changelog Pamoja na mfululizo wa barua pepe, pia hutumia ujumbe wa commit kujenga changelog hii na kuhifadhi katika faili inayoitwa CHANGELOG.md, ambayo inachukuliwa pamoja na alama ya toleo na mabomu ya toleo. vnext Imefichwa katika mtiririko wa kazi wa kutolewa niliyoshiriki hapo juu, faili hii inatumiwa kama mwili wa kutolewa kwa GitHub. Mradi huo mwenyewe: vnext Toleo hili lilikuwa toleo la patch, kwa sababu lilikuwa na ufumbuzi, katika fomu ya bump ya toleo la kujitegemea, na idadi ya kazi nyingine. Maelezo haya ya uwasilishaji huonekana baadaye katika zana zingine, kama vile , chombo ambacho hufanya PRs kuweka utegemezi wako up-to-date. Urefu wa Wakati wa kuunganisha Maombi ya Pull, napenda kutumia kipengele cha Squash na Kuunganisha cha GitHub ili kuwa na fursa ya kuandika kichwa na mwili wa ujumbe mzuri wa mwisho ambao utatumiwa katika changelog. Kwa mfano: Kama ilivyoonyeshwa katika mfano, unaweza kuweka Markdown kamili kama mwili wa ahadi. Itakuwa kuonyeshwa kwa usahihi katika Maoni ya Kutolewa! Mwisho wa Najua versioning na kuchapisha sio mada ya sexy zaidi; ni kuchoka - au badala yake, inapaswa kuwa! Hata hivyo, hii sio daima kesi. Hiyo ndiyo sababu mimi kujenga na kundi la Sasa, ninaweza kuingia kwa urahisi katika miradi nyingi haraka sana! vnext Mipango ya kazi ya kushirikiana Natumaini hii itakuwa na manufaa kwako pia! Tafadhali soma ikiwa unatoa na baadhi ya mtiririko wa kazi ulioshirikiwa kujaribu! ningependa kuwashukuru baadhi ya nyota kwenye GitHub na kushirikiana ikiwa utaona kuwa muhimu! vnext
