چټک او آسانه CI / CD پایپونه د هر ژور یا آله لپاره سمینټیک نسخه کولو سره. د وسایلو نوي نسخه وړاندیز کول باید ناڅاپي وي. نه د مراسمو، نه د نندارتونونه، نه حتی د بحث. دا باید شفاف، آسانه، قابل اعتماد، او حتی معلوماتي وي - د دې په اړه نور وروسته. په هرصورت، لکه څنګه چې یو سافټویر مشاور چې ټیمونو کې مرسته کوي د DevOps حلونو په کارولو کې، زه ډیری وختونه پاملرنه کولی شي چې دا نه دی. هغه څه چې زه پاملرنه کولی شي په کیفیت کې پراخه کچه توپیر لري، نو د هغه څه لپاره چې زه نه غواړم، بیا په دې کې تمرکز وکړم چې څنګه زما د پایپولونو جوړولو لپاره په چټکۍ سره او آسانه توګه د نوي ذخیره کولو لپاره. د خپل نظریاتو درکولو لپاره، زه غواړم چې د دې موضوع په اړه زما نظرونه د کلونو په اوږدو کې څرنګه وده ورکړم. اوس مهال، زه د "LEGO بلاکونه" د ماډولر کار فورمهونو سره د کوچني تعدیلاتو سره تنظیم کولو پروسه کاروي. په عادي توګه، زه د معیاري ډولونو ته اړتیا ولرئ چې زه په ساده توګه د یو پروژې څخه د ورته جوړښتونو څخه یو پروژې ته راټول او پوښښئ کله چې دوی ورته ډول شریک کړي. د مثال په توګه، د Rust کتابتون X جوړولو پروسه احتمالا د Rust کتابتون Y سره ورته وي، او Node سرور foo احتمالا د Node سرور بار سره ورته وي. او داسې نور. د کلونو په اوږدو کې، زه هڅه کړې چې د دې لپاره د Open-Source برخو جوړ کړي، مګر زه هیڅکله د مناسب ترکیب نلري. ما په پایله کې زما د خپل حلونه جوړ کړم، او زه به د دوی سره په چټکۍ سره شریک کړي. لومړی ... زه پوهم چې نسخه کولو او ریکارډ کولو د ټولو هیجان زده کونکي موضوعاتو نه دي؛ په هرصورت، دا یو ستونزه ده چې هر پروژې ستونزه کوي، حتی کله چې vibe-coded (شاید په ځانګړې توګه!). نو، نو، موږ د دې په سمه توګه په اړه خبرې کوو. زما په نظر کې، البته. دا به ستاسو د پروژې ډیر مسلکي وي او د دې کاروونکو ته بدلونونه مخنیوی کړي. دا به د پروژو په اړه ډیر اعتماد جوړوي ترڅو د پروژو جوړونکو سره د نوي بدلونونو په واضح او تعقیب ډول درک او تصویب کولو کې مرسته وکړي. په پیل کې ... زما د سافټویر انجنيرۍ د کارموندنې په پیل کې، ریکارډونه د واقعیت دی. دوی د موټرو محصول دي، د سپینټونو لړ له لارې ترسره شوي، چې د هرڅوک وړتیا څخه ترټولو غوره، په سیریز کې د برنامه کولو کنفرانسونو کې پلان شوي، په کوم کې د رخصتۍ له لارې راټول شوي، او د کارونو چې ارزښت لري انتخاب شوي دي. موږ به زموږ غوره کار وکړي چې د پلان لپاره د ځانګړتیاوو لیکل، او د Fibonacci شمیره یا T-Shirt اندازه، یا په بدترین حالت کې، د ډیرو ورځو په اړه اندازې کړي. البته، تل ځینې بڼه حلونه شتون لري چې د مخکښ ریکارډونه هم حل کړي. د رخصتۍ د دې پروسه د پیاوړتیا دی. د رخصتۍ د رخصتۍ، د واقعي کاروونکو ته لیږدول. لکه څنګه چې د دې پروسه د پیاوړتیا، او د دې لپاره لوړ شرطونه، د رخصتۍ د احساساتي وخت دی. هیله ورکړئ؟ ګرمه؟ ممکن چې ځینې تاسو ته وده ورکړئ ستاسو د دماغ په چټکۍ سره چې دوی د ماشينونو ته حرکت وکړي. همدارنګه د نسخې شمیره ټاکل کولو تفصيلات او ډرامات لري. دا یو لوی نسخه ده؟ په بشپړه توګه نوي نسخه؟ Minor؟ Patch؟ په ځینو وختونو کې د بازار موندنې نسخه ... 2.0 دا دی! په دې وخت کې زما د کارموندنې کې، دا په عمده توګه زما نظر نه وه چې په دې موضوع کې د نسخه شمیره مهمه وه، او په لوړه کچه وګورئ، دا احتمالا باید د هرڅوک نه وي ( تاسو به وګورئ چې زه وروسته په دې معنی). ما په پیل کې د وړاندیزونو لپاره مسؤل نه وه ... په هرصورت ... دا به تل نه وي. په Open Source کې په ځینې وختونو کې زما د کارموندنې کې، زه په پراخه توګه د نندارتونونو په شکل کې، لکه څنګه چې زه په دې وخت کې ډېر په نندارتون کې وه. د رخصتۍ په اړه د مراجعینو په کارولو کې زما په لټه کې وي. زه نه یاد ولرئ چې څنګه، شاید ځینې نیوزلینز له لارې یا شاید د NYC NodeJS meetup برخه کې چې ماټ والترس او زه په ګډه چلول - ما د کتابتون سره راځي Semantic Release یو اصول جوړ کړ، کوم چې زه د ویب ډیزاینر په توګه په پام کې ونیسئ، د مسؤلیت په اساس د مسؤلیت په اساس. semantic-release مخکې له دې چې تاسو په کارولو سره کار واخلئ او Semantic-Release کارولو پیل کړئ، زه د دې سره ځینې محدودیتونه شتون لري ... او زه به په ځینې وختونو کې یې ترلاسه کروں. لومړی، په لوړ کچه، د اساسي مفکوره چې semantic-release مخکښ وه چې تاسو به ستاسو د commit پيغامونو لپاره د ځانګړي فارم پیژندل کړي، او د پيغامونو له مخې، د نسخه کولی شي محاسبه شي. دا د ریلیزونو څخه د احساسونو له لاسه ورکولو په اړه خبرې کوي، دوی روبوټ جوړوي، پر بنسټ چې څه په واقعیت کې بدل شوی. دا د نسخه شمیره بدلولو اجازه ورکوي چې څه بدل شوی دی. که یو نوي لوی نسخه راځي - v2 ته v3، د بیلګې په توګه، دا معنی لري چې یو رواني بدلون شتون لري. د دې معنی لپاره په خپل commit پیغام کې، تاسو به شامل کړئ د commit په بدن کې. 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! د کوچني نسخه نندارتونونه، لکه v2.0.0 ته v2.1.0، د یو نوی ځانګړتیا اضافه شوي دي. 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. د پټچ ورژنونه د اصلاحاتو، یا refactors، یا په عمده توګه هر څه نور چې باید د نوي وړاندیز ته وده ورکړي. fix: revert "fix" by AI that skipped the breaking tests to avoid the failure او په پایله کې، ځينې تعهدات باید په ټولو کې د رخصتۍ له امله نلري. "د کارونو" لکه څنګه چې دوی زما ته معرفی شوي دي. نه-ops، لکه څنګه چې زه دوی ته ووي. chore: update release pipeline version from v3.1.0 to v3.1.1 د commit پیغامونو د دې ځانګړي فارم په توګه نومول شوی ، که څه هم نور دي. تاسو کولی شئ د بشپړ ځانګړتیاوې لپاره د دوی پاڼه وګورئ، مګر زه غواړم چې د هغې د ګرځنده برخه واخلئ. د معمولي شرکتونه برسېره پر دې، دا معلوماتو په commits کې شامل شي هم کولای شي په توګه د بدلون ریکارډ په توګه ښودل شي - لکه د بېرته بدلون ته وده ورکوي. د مثال په توګه: 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. نو، د ځینې وختونو لپاره، Semantic-Release زما لپاره ښه دی. د Node پروژو لپاره، دا اوس هم دی ... په هرصورت ... د DevOps ما تل په دې مفکوره کې دلچسپي لري چې څنګه د پراختیا وړ توزیع شوي سیسټمونه جوړ کړي، او نو دا هغه څه دی چې ما په خپل کاروبار کې ډیری وختونو لپاره هڅه کړم. اوږد تاریخ خلاص، ما په پایله کې زده کړې چې څنګه دا ښه کړي، مګر یو نوي ستونزه شتون لري: څنګه د ټولو ټوټې ته وده ورکړي. دا د npm ماډل نه دي؛ دوی د غوښتنلیکونه، خدمتونه، ډاټا بیسونه او رنګونه دي! ما د Semantic-Release سادهۍ څخه خوند واخلئ، مګر دا یوازې د Node.js پروژو لپاره ښه کار کوي. البته، تاسو کولی شئ، او زه ځینې وختونه کار وکړم، د Node.js پروژو لپاره ښه کار وکړئ. په غیر نود پروژو کې فایل کړئ، مګر دا په غوره توګه خراب او hacky دی. package.json په دې وخت کې، زه د Jenkins عمر کې د DevOps په عمده توګه ګډون وکړم، لکه څنګه چې Docker پیل کړ چې د ټریټینټ ترلاسه کړي. زه د Jenkins سره pipelines لیکنه او په Docker Swarm سره ټولې کارونو ته ورسیږي! زما د DevOps سفر او د ډیزاین لپاره د Docker کشف. زه هم په هغه وخت کې د ټرانک پر بنسټ د پراختیا په لټه کې و، او د ماسټرولو ته وده ورکړم. زما وروستۍ او اوس هم اړین او دقیق لارښود د ټرانک پر بنسټ د پراختیا لارښود مقاله توضیح کوي که تاسو دلچسپي لرئ نو څنګه او څنګه. زه هم په هغه وخت کې د ټرانسپورټ پر بنسټ د پراختیا په لټه کې و، او زما د وروستیو او اوس هم مهم او دقیق مقاله توضیح کوي چې څومره او څنګه، که تاسو دلچسپي لرئ. د ماسټر په اړه د Trunk-Based پراختیا سره د Git لپاره لارښود زه تل غواړم چې د دې پروژو سره چې زه کار وکړم ویډیوګانې شي او د semantic-release پروژو په څیر وړاندیز شي، مګر زه هیڅکله د حل نه لرم چې هم کار کوي. ډیری به د Changelogs جوړولو په سمه توګه کار نه کړي، او ځینې به په ځینې وختونو کې د نسخه غلط کړي. دا زما په لیست کې تر ټولو مهمې څه نه وه، نو زه په عمومي توګه دا ډیره ښه وه او د نقصونو سره ژوند وکړم. د وخت په توګه، د DevOps مشورې په توګه، زه په ډیرو ژبو او frameworks کې مختلف پروژو سره ونیسئ او خپور کړم، او هر یو د نسخه کولو، خپورونو او Changelogs ته اړتیا لري. یو بل دماغ درد چې زه ډیری وختونه په لټه کې وه، لوی، monolithic پایپونه. له Jenkins عمر څخه راځي، زه یې ترلاسه کړ، دا دا ده چې زه هم د پایپونو په نامه کار واخلئ. زه به هڅه کولی شي چې د بشپړ وړاندیز د جریان په یوه لوی لړ کې، سره د اصلي په پیل کې. که تاسو د اصلي ته فشار ورکړئ، د مختلفو کیفیت چکونه به ترسره شي، او یو نوی نسخه به جوړ شي، خپور شي، tagged، او خپور شي. دا په ځان کې نه ده او همدارنګه احتمالا په ډیری صورتونو کې "د ښه" ده؛ په هرصورت، د DevOps مشاور په توګه، زه باید دا تکرار وکړم. د کوچني، زيات ماډولر ټوټهونو ته د دې ټوټهونو ته اجازه ورکوي چې نور پروژې خدمت وکړي. زه لومړی دا د نامتو جیمز Halliday، AKA Substack، له خوا په دې اړه خبرې وکړم. ، یو مفکوره چې د UNIX فلسفې په پام کې راځي. د افکار د پوښونو د مثال په توګه، د Node د کیفیت پایپینډ په هر Node پروژې کې ورته وي، که څه هم تاسو د معياري npm سکرپټ کنوانسیونونو پیژندل کړئ، او نو د لټون کولو، جوړولو او واحد ازموینې لپاره د عمومي پایپینډ د Node.js پروژو اکثریت، اگر نه ټول کې شریک شي. او داسې نور، او د کتابونو برخه د د فایل مشخصوي چې کله چې دا ترسره کیږي د فرمان د چلولو. npm run lint --if-present package.json lint د Versioning او Releasing لپاره د لوړ کچه پایپولونه په لوړه کچه، هر پروژې چې اړتيا لري چې راټول شي لومړی به د نوي نسخه شمیره لرې شي. بيا، کولای شي يو نسخه جوړ شي چې د دې نسخه شمیره تړل کیږي، او د انجنونه به د هغې سره تړل شوي پمپونو په برخه کې تولید شي. زه تر ټولو اغیزمن ډول GitHub Actions کاروي، ځکه چې زه فکر کوم چې پایپینډونه د خامو موادو دي، او دا یو ساده کار دی چې پیل کړئ. زه ډیری کاروئ، مګر دوی ټول په عمده توګه ورته دي - د مشترکه حجم سره یو لړ لارښوونې ترسره کړئ. دا مشترکه حجم عموما د چک شوي سرچینې کوډ لري. Versioning ځان، که موږ د conventional commits معياري پیژندل کیږي چې د semantic version increasing سره تړاو لري، دا د زبان ځانګړي څه نه ده. دا د کوډ محتویاتو په اړه د تقاضا نه لري؛ په بل کې، دا د نسخه او commits تاریخ په اړه دي. په اوږدو وخت کې، زه نسخهونو ته ورسیږي، فکر کوم چې دوی د ورته څه په برخه کې دي، کله چې په واقعیت کې، دوی دوه مختلف انجن دي چې یوځای شوي دي. د دوی په برخو کې تقسیم کول د پایپینګ versioning برخه خپل ماډولیک ټوټې جوړ کړ، کوم چې بیا د دې نسخه جوړولو او د راتلونکي وړاندیز ته وده ورکړي. د هر پروژې لپاره، په GitHub Actions، زه دوه پایپولونه لري: 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. لکه څنګه چې زه مخکې اشاره کړم، د GitHub Actions Marketplace څخه د open-source برخو په ګډه هڅه کولو وروسته، زه په پایله کې د خپل وسایلو جوړ کړم چې د مرحله یو په کارولو سره کار کوي. زه هم ځینې کار فریکونسونه جوړ کړم، کوم چې زه به تاسو سره هم شریک وکړم. نندارتون ولډنګ ولډنګ vnext ده یو چټک Rust CLI وسیله چې د معمولي commit پیغامونه کاروي ستاسو د راتلونکي سمینټیک نسخه محاسبه، د عمده، کوچني، او یا patch بامونو لپاره د سټیلینډ وړاندیزونو لپاره اتومات. دلته څنګه دا کاروي. NEXT_VERSION=v`vnext` vnext --changelog > CHANGELOG.md زه فکر کوم چې دا ډیره ساده دی! اجازه وکړم پوه شي چې تاسو څه فکر کوي. دا په بشپړه توګه د پروژې git تاریخ پر بنسټ. دا مهمه نه ده چې تاسو کوم ژبه یا وسایلو وړاندیز وکړئ؛ د نسخه کولو پروسه په عمده توګه ورته دی. د نوي نسخه ترلاسه کړئ، دا په ځينو فایلونو کې تازه کړئ، د Changelog، Tag، او پمپ جوړ کړئ. یوازې فرق دی چې هغه فایلونه چې اړتیا لري تازه شي - دا په کار فورمه کې حساب ورکوي چې زه به په ځینې وختونو کې شریک کړئ. چټک او آسانه د نصب له لارې - د . کله چې تنظیم شوی، تاسو کولی شئ د کارولو: vnext ubi د "Universal Binary Installer" په اړه ubi --project unbounded-tech/vnext زه هم یو مشترکه GitHub د عملونو د workflow جوړ کړم چې تاسو کولی شئ په تماس کې ونیسئ، کوم چې د دې معلوماتو سره کار کوي. دلته دا ده چې څنګه د مشترکه کار فورمه کاروي: 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 ډیری پروژې به هم اړتیا ولري چې څنګه او هغه فایلونه چې د نوي نسخه شمیره تازه کړي. اوس مهال، د دوو ژرنیک سټیشنونه ملاتړ کوي ( او ) او ځینې ژوره ځانګړي انتخابونه. vnext yqPatches regexPatches د زبان ځانګړي انتخابونه د کارولو په ساده ترین ډول دي. د مثال په توګه، د د کارول د پروژې د بسته فایلونو تازه کولو لپاره. with.node true npm د وسیله کارول په یو YAML فایل کې د ځانګړي پوښونو د پوښونو لپاره. زه په اغیزمن ډول د هیلم ګرافونو کې د نسخه شمولاتو تازه کولو لپاره دا کاروي: 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" زه هم د دې فرصت څخه ګټه واخلئ چې څنګه د پراختیا کلید په جای کې د شخصي لاس رسی ټکین کاروي. زه هم د دې فرصت څخه ګټه واخلئ چې څنګه د پراختیا کلید په جای کې د شخصي لاس رسی ټکین کاروي. کارول د نوي نسخه شمیره د لګولو او بدلولو لپاره. د مثال په توګه: 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 تاسو کولی شئ د انتخابونو ترکیب هم کار واخلئ. د GitHub فعالیتونو په اړه یو نندارتون کله چې تاسو په GitHub Actions کې یو عمل ترسره کړئ، د کارکوونکي د موقتي GitHub تصدیق ټکین تولید کوي. دا ټکین د ځینې بنسټیزې کارونو ترسره کولو اجازه لري؛ په هرصورت، دا هرگز اجازه نلري چې د نورو پایپینګونو له لارې کار وکړي. مګر د نوي نسخه تګولو وروسته زموږ راتلونکي مرحله دا دی چې د دې تګ سره یو بل پایپینټ چمتو کړئ! فکر نه وکړئ، دا د ډیزاین لخوا دی - یوازې د GitHub لخوا د غیرقانوني ډیری چلونکي څخه مخنیوی کولو لپاره. تاسو اجازه لرئ چې دا وکړئ، مګر تاسو باید په اسانه توګه په دې کې وي. د دې په اړه ډیری لارهونه شتون لري - زه اوس د دوو مثالونه ښيي: د تبادلې کلید او د GitHub Actions Secret په کارولو سره د شخصي لاسرسي ټکین کارولو په توګه د GitHub عمل راز د GitHub غوښتنلیک جوړولو (د نظریاتو په اړه - زه د دې اختیاري ته اړتيا نه لري) د شخصي لاسرسي ټکین کارولو مناسب دی که تاسو په GitHub اکوسیسټم کې د پیسو پیرودونکي یاست، ځکه چې ټول سازمان رازونه شتون لري. په وړیا کچه، دا یو انتخاب نه ده، نو زه به تاسو ته ښيي چې څنګه د پلور کلید جوړ کړئ. په حقیقت کې، زه دا په ساده توګه جوړ کړم دا په CLI. دا یو ښه انتخاب دی، لکه څنګه چې کله چې په دې ډول ترتیب شوي، هیڅ انسان باید دا پوه شي، او دا کولای شي په اسانۍ سره په ورته امر کې راټول شي. vnext د هر د ذخیره کولو لپاره چې تاسو غواړئ جوړ کړئ د پروژې لیږد کې، د پروژې لیږد کې د پلور کلید سره ... vnext لومړی، د auth token کارولو سره ترلاسه کړئ د کلیدونو اداره کولو اجازه سره: gh gh auth refresh -h github.com -s admin:public_key -s admin:ssh_signing_key export GITHUB_TOKEN=$(gh auth token) او بیا د چلولو: vnext generate-deploy-key تاسو کولی شئ فکر وکړئ، آیا دا به په یو پایپینډ کې نه وي؟ بدقسمه، زه کولی شئ په ګیتوب فعالیتونو کې د شخصي لاسرسي ټکین جوړولو پرته د دې مرحله اتومات کړي، ځکه چې د معياري ټکین د رازونو بدلولو نه کوي. دا د وړیا کچه په ځای کې د پراختیا کلید په کارولو د پپوزو څخه شکست کوي، ځکه چې تاسو باید دا په هر ریپو کې جوړ کړئ. دا د آسانه کولو لپاره یو ډول راز مدیریت ته اړتيا لري، او په دې توګه دا د پراختیا کلید په کارولو څخه ډیر کار کوي. زه په دې فکر وکړم. :) تاسو کولی شئ فکر وکړئ، آیا دا به په یو پایپینډ کې نه وي؟ بدقسمه، زه کولی شئ په ګیتوب فعالیتونو کې د شخصي لاسرسي ټکین جوړولو پرته د دې مرحله اتومات کړي، ځکه چې د معياري ټکین د رازونو بدلولو نه کوي. دا د وړیا کچه په ځای کې د پراختیا کلید په کارولو د پپوزو څخه شکست کوي، ځکه چې تاسو باید دا په هر ریپو کې جوړ کړئ. دا د آسانه کولو لپاره یو ډول راز مدیریت ته اړتيا لري، او په دې توګه دا د پراختیا کلید په کارولو څخه ډیر کار کوي. زه په دې فکر وکړم. :) سره ستاسو د اپلوز کلید، یا د شخصي لاس رسی ټکین (PAT)، په ځای کې، او د نسخه او ټایټ د کار د جریان په پرته د خپل ټیم فریکې ته فشار ورکوي، د راتلونکي مرحله د آزادولو ده! دا به د پروژې په اړه توپیر لري، مګر دوی ټول د مخکښې نسخه له خوا د مخکښې مرحله څخه تادیه کیږي. دا پایپونه عموما به د دې په څیر وي: 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 }} یا، که دا د Rust پروژې وي، ممکن دا څنګه وي: 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" یا که دا د Dockerfile سره یو غوښتنلیک وي، او k8s د Gitops پراختیا لپاره د سرچینې تعریفونه، ممکن دا یو څه شتون لري: 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 یادونه: د پلور کلیدونه کولی شي د نورو repo ته فشار نه کړي، لکه په gitops پرومو مرحله کې، نو تاسو کولی شئ د دې repo لپاره په هر ځای کې د PAT کارولو په پام کې ونیسئ. که تاسو د دې په څیر ډیری workloads لري، دا ممکن د هر repo په انفرادی ډول ترتیب کولو په پرتله د سازماني پراخ رازونو لپاره ارزښت لري. یادونه: د پلور کلیدونه کولی شي د نورو repo ته فشار نه کړي، لکه په gitops پرومو مرحله کې، نو تاسو کولی شئ د دې repo لپاره په هر ځای کې د PAT کارولو په پام کې ونیسئ. که تاسو د دې په څیر ډیری workloads لري، دا ممکن د هر repo په انفرادی ډول ترتیب کولو په پرتله د سازماني پراخ رازونو لپاره ارزښت لري. په عمومي توګه، هر نسخه د دغو ورته ماډلونو ځینې ټوټې ترکیب دی، کوم چې په عمده توګه ورته کارونه کوي مګر د دوی ځانګړي وسایلو یا ژورونو لپاره. عموما، سازمانونه لږ تر لږه هڅه کوي چې د غوښتنلیکونو او خدمتونو په اړه د ورته نمونې څخه ډیری پیژندل کړي، او له دې امله د کار فریکونسۍ په مشترکه ماډولر ټوټهونو کې وده ورکوي، د پراختیا کوونکو ته اجازه ورکوي چې په دې ډول هر پروژې ته د دې مشترکه کار فریکونسۍ د غوښتنلیکونو د خوښۍ کاپي او پوښښ کړي. د Changelogs سره مطابقت وړ تاسو کولی شئ پوه شئ چې زه په څیر په څیر د په نسخه مرحله کې نندارې. زه غواړم چې په دې کې راټول شي، ځکه چې دا د بالغ وړاندیز پروسه مهم برخه ده. Changelog دا ده چې تاسو کولی شئ د دې طریقو سره د نورو پراختیاو سره اړیکه ونیسئ چې ستاسو د پروژې بدل دی. with.changelog د Bumping نسخهونو په ګډه، هم د commit پیغامونه کاروي ترڅو دې changelog جوړ کړي او دا په CHANGELOG.md نامتو فایل کې ذخیره کیږي، کوم چې د نسخه ټګ او نسخه بامونو سره شریک کیږي. vnext مخکښ په هغه وړاندیز workflows چې زه په اوسط کې برخه واخلئ، دا فایل د GitHub وړاندیز د بدن په توګه کارول کیږي. د مثال په توګه، د د پروژې ځان: vnext دا نسخه د پیچ نسخه دی، ځکه چې دا یو حل، په شکل کې د انفرادي نسخه بام، او د نورو کارونو شمېر لري. د دې وړاندیز نوټونه وروسته په نورو وسایلو کې ښودل کیږي، لکه ، یو وسایلو چې د PRs لپاره ستاسو د تقاطعاتو په اټکل کې مرسته کوي. د Renovate کله چې Pull Requests یوځای کړئ، زه غواړم د GitHub Squash and Merge ځانګړتیاوو څخه کار واخلئ ترڅو وړتیا ولرئ چې په Changelog کې کارول کیږي. د مثال په توګه: لکه څنګه چې په مثال کې ښيي، تاسو کولی شئ په بشپړه کچه د Markdown په توګه د commit بدن جوړ کړئ. دا به په Release Notes په مناسب توګه ورسیږي! د پایلو زه پوهم چې نسخه کولو او د ریکارډ کولو په اړه ترټولو ښکلي موضوع نه ده؛ دا ډیر خسته ده - یا بل، دا باید وي! په هرصورت، دا تل نه دی. نو له دې امله زه جوړ او د اوس، زه کولی شي په اسانۍ سره د ډیری پروژو په ډیری وختونو کې! vnext د همکارۍ د workflows امیدوارم چې تاسو هم په کارولو سره مرسته وکړئ! مهرباني وکړئ موږ ته خبر وکړئ که تاسو د زه به د GitHub په اړه ځینې ستراتیژۍ او یو برخه واخلئ که تاسو یې ګټور وګورئ! vnext
