Bir yaz\u0131l\u0131m projesini paketlemek ve yay\u0131mlamak, geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fcn en kritik ancak s\u0131k\u00e7a g\u00f6z ard\u0131 edilen ad\u0131mlar\u0131ndan biridir. Repo-context-packager kavram\u0131, bu s\u00fcreci otomatikle\u015ftirerek geli\u015ftiricilere zaman kazand\u0131r\u0131r ve hata riskini azalt\u0131r. Bu makale, repo-context-packager’\u0131n ne oldu\u011funu, neden gerekli oldu\u011funu ve projelerinizde nas\u0131l etkin bir \u015fekilde kullan\u0131labilece\u011fini ad\u0131m ad\u0131m a\u00e7\u0131klayacakt\u0131r.<\/p>\n
Modern yaz\u0131l\u0131m geli\u015ftirme, s\u00fcrekli entegrasyon ve s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) prensiplerini benimser. Ancak bu prensiplere ra\u011fmen, bir yaz\u0131l\u0131m projesini “yay\u0131ma haz\u0131r” hale getirmek \u00e7o\u011fu zaman karma\u015f\u0131k ve hataya a\u00e7\u0131k bir s\u00fcre\u00e7 olmaya devam eder. Manuel s\u00fcr\u00fcm etiketlemesi, ba\u011f\u0131ml\u0131l\u0131k y\u00f6netimi, farkl\u0131 ortamlar i\u00e7in yap\u0131land\u0131rma dosyalar\u0131n\u0131n g\u00fcncellenmesi ve \u00e7\u0131kt\u0131 paketlerinin do\u011fru formatta olu\u015fturulmas\u0131 gibi ad\u0131mlar, geli\u015ftiricilerin vaktinin \u00f6nemli bir k\u0131sm\u0131n\u0131 al\u0131r. \u00dcstelik bu manuel ad\u0131mlar, insan hatas\u0131na davetiye \u00e7\u0131kararak beklenmedik \u00fcretim sorunlar\u0131na yol a\u00e7abilir.<\/p>\n
\u00d6rne\u011fin, bir geli\u015ftiricinin yanl\u0131\u015fl\u0131kla bir \u00f6nceki s\u00fcr\u00fcm numaras\u0131n\u0131 kullanmas\u0131 veya test ortam\u0131 i\u00e7in haz\u0131rlanm\u0131\u015f bir yap\u0131land\u0131rma dosyas\u0131n\u0131 \u00fcretim ortam\u0131na g\u00f6ndermesi, ciddi sonu\u00e7lar do\u011furabilir. B\u00fcy\u00fck \u00f6l\u00e7ekli projelerde veya mikroservis mimarilerinde, her bir bile\u015fenin kendi ya\u015fam d\u00f6ng\u00fcs\u00fc ve ba\u011f\u0131ml\u0131l\u0131klar\u0131 oldu\u011fu i\u00e7in bu karma\u015fa katlanarak artar. Her bir mikroservisin do\u011fru versiyonunun do\u011fru zamanda do\u011fru hedefe ula\u015ft\u0131\u011f\u0131ndan emin olmak, ba\u015fl\u0131 ba\u015f\u0131na bir y\u00f6netim y\u00fck\u00fcd\u00fcr. Bu durum, geli\u015ftirme ekiplerinin inovasyona odaklanmak yerine operasyonel s\u00fcre\u00e7lerle bo\u011fu\u015fmas\u0131na neden olur.<\/p>\n
\u0130\u015fte tam da bu noktada, “repo-context-packager” kavram\u0131 devreye giriyor. Bu yakla\u015f\u0131m, bir projenin yay\u0131nlanmaya haz\u0131r paketlerini olu\u015ftururken, kaynak kod deposunun (repository) o anki ba\u011flam\u0131n\u0131 (context) dikkate al\u0131r. Yani, hangi daldan (branch) yay\u0131n yap\u0131ld\u0131\u011f\u0131, hangi commit \u00fczerinde bulunuldu\u011fu, mevcut etiketler (tags), hatta projenin dosya yap\u0131s\u0131 gibi bilgileri kullanarak dinamik ve tutarl\u0131 paketler \u00fcretir. Bu sayede, manuel m\u00fcdahaleyi en aza indirerek hem s\u00fcr\u00fcm tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flar hem de geli\u015ftirme d\u00f6ng\u00fcs\u00fcn\u00fc h\u0131zland\u0131r\u0131r. S\u00fcrekli entegrasyon sunucular\u0131n\u0131n (\u00f6rne\u011fin Jenkins, GitLab CI, GitHub Actions) bu t\u00fcr bir ba\u011flamsal paketleyici ile entegrasyonu, yay\u0131mlama s\u00fcrecini tamamen otomatikle\u015ftirmenin kap\u0131lar\u0131n\u0131 aralar. Bu, sadece hatalar\u0131 azaltmakla kalmaz, ayn\u0131 zamanda ekiplerin daha s\u0131k ve g\u00fcvenli bir \u015fekilde \u00fcretim ortam\u0131na deploy yapabilmesine olanak tan\u0131r. Bir pastay\u0131 f\u0131r\u0131na atmadan \u00f6nce t\u00fcm malzemelerin do\u011fru oranlarda ve taze oldu\u011fundan emin olmak gibidir; her \u015fey m\u00fckemmel bir sonu\u00e7 i\u00e7in do\u011fru yerinde olmal\u0131d\u0131r. Repo-context-packager da bu “m\u00fckemmel sonu\u00e7” i\u00e7in gerekli ba\u011flam\u0131 sa\u011flar.<\/p>\n
Repo-context-packager, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, bir yaz\u0131l\u0131m projesini paketlerken (packager) projenin kaynak kod deposunun (repo) mevcut durumunu ve \u00e7evresel ko\u015fullar\u0131n\u0131 (context) dikkate alan bir yakla\u015f\u0131m veya ara\u00e7 setidir. Temel amac\u0131, paketleme ve yay\u0131mlama s\u00fcre\u00e7lerini otomatikle\u015ftirirken, olu\u015fturulan paketlerin i\u00e7eri\u011fini, s\u00fcr\u00fcm\u00fcn\u00fc ve meta verilerini projenin anl\u0131k ba\u011flam\u0131yla senkronize etmektir. Bu, \u00f6zellikle karma\u015f\u0131k projelerde veya \u00e7oklu mod\u00fcll\u00fc depolarda (monorepo) tutarl\u0131l\u0131k ve g\u00fcvenilirlik sa\u011flamak i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n
Peki, bu “ba\u011flam” tam olarak ne anlama geliyor? Ba\u011flam, a\u015fa\u011f\u0131daki gibi \u00e7e\u015fitli bilgileri i\u00e7erebilir:<\/p>\n
Repo-context-packager’\u0131n temel bile\u015fenleri ve i\u015fleyi\u015fi genellikle \u015fu ad\u0131mlar\u0131 i\u00e7erir:<\/p>\n
repo-context-packager.config.js<\/code>), packager’\u0131n nas\u0131l davranaca\u011f\u0131n\u0131 tan\u0131mlar. Bu dosya, hangi dizinlerin paketlenece\u011fini, hangi komutlar\u0131n \u00e7al\u0131\u015ft\u0131r\u0131laca\u011f\u0131n\u0131 (build, test), s\u00fcr\u00fcm\u00fcn nas\u0131l belirlenece\u011fini ve yay\u0131mlama hedefini (npm, Docker Hub vb.) belirtir.<\/li>\n- S\u00fcr\u00fcm Belirleme:<\/strong> Toplanan ba\u011flam bilgileri (\u00f6rn. git tag veya commit SHA) ve yap\u0131land\u0131rma dosyas\u0131 kullan\u0131larak pakete benzersiz ve tutarl\u0131 bir s\u00fcr\u00fcm atan\u0131r. Bu, manuel s\u00fcr\u00fcm \u00e7ak\u0131\u015fmalar\u0131n\u0131 veya yanl\u0131\u015f etiketlemeyi engeller.<\/li>\n
- Paket Olu\u015fturma:<\/strong> Tan\u0131mlanm\u0131\u015f build komutlar\u0131 \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r ve \u00e7\u0131kt\u0131 dizinindeki dosyalar toplanarak hedef paket format\u0131na d\u00f6n\u00fc\u015ft\u00fcr\u00fcl\u00fcr (\u00f6rn.
.tgz<\/code>, .jar<\/code>, Docker imaj\u0131).<\/li>\n- Yay\u0131mlama:<\/strong> Olu\u015fturulan paket, belirtilen hedef depo veya registry’ye (\u00f6rn. npm registry, Docker Hub, Artifactory) yay\u0131mlan\u0131r. Bu ad\u0131m genellikle yetkilendirme (token, API key) gerektirir.<\/li>\n<\/ol>\n
Bu s\u00fcre\u00e7, her yay\u0131mlama i\u015fleminde tekrarlanarak, her paketin kendi repo ba\u011flam\u0131yla e\u015fle\u015fti\u011finden emin olur. Bu sayede, geli\u015ftiriciler ve operasyon ekipleri, bir paketin ne zaman, hangi ko\u015fullarda ve hangi kod taban\u0131ndan \u00fcretildi\u011fini her zaman bilebilirler. Bu \u015feffafl\u0131k ve otomasyon, hata ay\u0131klama s\u00fcre\u00e7lerini basitle\u015ftirir ve yaz\u0131l\u0131m kalitesini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. Dolay\u0131s\u0131yla, repo-context-packager, sadece bir ara\u00e7 de\u011fil, ayn\u0131 zamanda modern yaz\u0131l\u0131m geli\u015ftirme ve da\u011f\u0131t\u0131m felsefesinin \u00f6nemli bir par\u00e7as\u0131d\u0131r.<\/p>\n
Repo-Context-Packager ile \u0130lk Paketinizi Nas\u0131l Olu\u015fturursunuz?<\/h2>\n
Repo-context-packager’\u0131n ne oldu\u011funu ve neden \u00f6nemli oldu\u011funu anlad\u0131\u011f\u0131m\u0131za g\u00f6re, \u015fimdi pratik bir \u00f6rnek \u00fczerinden kendi ilk paketinizi nas\u0131l olu\u015fturaca\u011f\u0131n\u0131z\u0131 inceleyelim. Bu b\u00f6l\u00fcm, ad\u0131mlar\u0131 anla\u015f\u0131l\u0131r bir \u015fekilde a\u00e7\u0131klayarak konuya yabanc\u0131 olanlar\u0131n bile rahatl\u0131kla uygulayabilece\u011fi bir rehber sunacakt\u0131r. Varsay\u0131msal bir Node.js projesi ve NPM ekosistemi \u00fczerinden ilerleyece\u011fiz, ancak temel prensipler farkl\u0131 diller ve paket y\u00f6neticileri i\u00e7in de benzerdir.<\/p>\n
Gerekli Ortam Kurulumu: Ba\u015flamak \u0130\u00e7in Ne Laz\u0131m?<\/h3>\n
Ba\u015flamadan \u00f6nce, sisteminizde baz\u0131 temel ara\u00e7lar\u0131n y\u00fckl\u00fc oldu\u011fundan emin olmal\u0131s\u0131n\u0131z:<\/p>\n
\n- Node.js ve npm:<\/strong> JavaScript tabanl\u0131 bir paketleyici kullanaca\u011f\u0131m\u0131z i\u00e7in Node.js ve paket y\u00f6neticisi npm’in kurulu olmas\u0131 gerekir.<\/li>\n
- Git:<\/strong> Repo ba\u011flam\u0131n\u0131 okumak i\u00e7in Git’e ihtiyac\u0131m\u0131z var.<\/li>\n
- Bir Proje Klas\u00f6r\u00fc:<\/strong> \u00d6rnek bir uygulama olu\u015ftural\u0131m. Ad\u0131 “my-awesome-library” olsun.<\/li>\n<\/ul>\n
\nmkdir my-awesome-library\ncd my-awesome-library\ngit init\nnpm init -y\ntouch src\/index.js\necho \"export const greet = (name) => Hello, ${name}!<\/code>;\" > src\/index.js\n <\/pre>\n<\/code><\/p>\n
\u015eimdi projemize basit bir build s\u00fcreci ekleyelim. Genellikle Babel gibi bir transpiler kullan\u0131l\u0131r. \u00d6rne\u011fimiz i\u00e7in basit bir Babel kurulumu yapal\u0131m:<\/p>\n
\nnpm install --save-dev @babel\/core @babel\/cli @babel\/preset-env\n <\/pre>\n<\/code><\/p>\n
Ard\u0131ndan, .babelrc<\/code> ad\u0131nda bir yap\u0131land\u0131rma dosyas\u0131 olu\u015ftural\u0131m:<\/p>\n\n\/\/ .babelrc\n{\n \"presets\": [\"@babel\/preset-env\"]\n}\n <\/pre>\n<\/code><\/p>\n
package.json<\/code> dosyan\u0131za a\u015fa\u011f\u0131daki build script'ini ekleyin:<\/p>\n\n{\n \"name\": \"my-awesome-library\",\n \"version\": \"1.0.0\",\n \"description\": \"A demo library packaged with repo-context-packager\",\n \"main\": \"dist\/index.js\",\n \"scripts\": {\n \"build\": \"babel src -d dist --copy-files\",\n \"test\": \"echo \\\"Error: no test specified\\\" && exit 1\"\n },\n \"keywords\": [],\n \"author\": \"\",\n \"license\": \"ISC\",\n \"devDependencies\": {\n \"@babel\/cli\": \"^7.23.0\",\n \"@babel\/core\": \"^7.23.3\",\n \"@babel\/preset-env\": \"^7.23.3\"\n }\n}\n <\/pre>\n<\/code><\/p>\n
Art\u0131k npm run build<\/code> komutunu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131zda, dist<\/code> klas\u00f6r\u00fc i\u00e7ine transpiled kodunuz olu\u015fturulacakt\u0131r.<\/p>\nPaketleme ve S\u00fcr\u00fcmlendirme Nas\u0131l Yap\u0131l\u0131r?<\/h3>\n
\u015eimdi, repo-context-packager'\u0131n kalbine inelim. Varsay\u0131msal bir repo-context-packager<\/code> CLI arac\u0131 kullanaca\u011f\u0131z. Bu ara\u00e7, genellikle bir npm paketi olarak bulunur. \u00d6nce onu kural\u0131m:<\/p>\n\nnpm install --save-dev repo-context-packager\n <\/pre>\n<\/code><\/p>\n
Ard\u0131ndan, projenizin k\u00f6k dizininde repo-context-packager.config.js<\/code> ad\u0131nda bir yap\u0131land\u0131rma dosyas\u0131 olu\u015ftural\u0131m. Bu dosya, paketleme s\u00fcrecinin t\u00fcm detaylar\u0131n\u0131 bar\u0131nd\u0131racak:<\/p>\n\n\/\/ repo-context-packager.config.js\nconst { execSync } = require('child_process');\n\nmodule.exports = {\n \/\/ Kaynak kod dizini\n sourceDir: '.\/src',\n \/\/ Build sonras\u0131 \u00e7\u0131kt\u0131lar\u0131n bulunaca\u011f\u0131 dizin\n outputDir: '.\/dist',\n \/\/ Paketin ad\u0131 (package.json'daki ile uyumlu olmal\u0131)\n packageName: 'my-awesome-library',\n \/\/ S\u00fcr\u00fcm\u00fcn nereden al\u0131naca\u011f\u0131n\u0131 belirtin: 'git-tag', 'git-commit', 'package.json'\n versionSource: 'git-tag', \/\/ E\u011fer git tag yoksa, package.json'a fallback yapabilir\n \/\/ Paketi olu\u015fturmadan \u00f6nce \u00e7al\u0131\u015ft\u0131r\u0131lacak build komutu\n buildCommand: 'npm run build',\n \/\/ Paketi olu\u015fturduktan sonra yay\u0131nlamak i\u00e7in kullan\u0131lacak komut\n \/\/ Bu genellikle npm publish veya benzeri bir komut olur\n publishCommand: (version) => {\n \/\/ Publish \u00f6ncesi package.json'daki versiyonu g\u00fcncelleme\n execSync(npm version ${version} --no-git-tag-version<\/code>);\n return npm publish --access public<\/code>;\n },\n \/\/ Paketleme s\u0131ras\u0131nda eklenmesini istedi\u011finiz ba\u011flam de\u011fi\u015fkenleri\n contextVariables: {\n GIT_COMMIT_SHA: true,\n GIT_BRANCH: true,\n BUILD_DATE: new Date().toISOString()\n },\n \/\/ S\u00fcr\u00fcm format\u0131n\u0131 \u00f6zelle\u015ftirme\n \/\/ \u00d6rne\u011fin, 'v1.0.0' yerine '1.0.0' veya '1.0.0-beta.gabcdef'\n versionFormat: (baseVersion, context) => {\n if (context.GIT_BRANCH && context.GIT_BRANCH !== 'main' && context.GIT_BRANCH !== 'master') {\n return ${baseVersion}-${context.GIT_BRANCH.replace(\/\\\/\/g, '-')}.g${context.GIT_COMMIT_SHA.substring(0, 7)}<\/code>;\n }\n return baseVersion;\n }\n};\n <\/pre>\n<\/code><\/p>\n
\u015eimdi bir Git commit'i yapal\u0131m ve bir etiket olu\u015ftural\u0131m:<\/p>\n
\ngit add .\ngit commit -m \"Initial commit of my awesome library\"\ngit tag v1.0.0\n <\/pre>\n<\/code><\/p>\n
Art\u0131k paketinizi olu\u015fturup yay\u0131mlamak i\u00e7in repo-context-packager<\/code>'\u0131 kullanabilirsiniz. E\u011fer npm registry'ye yay\u0131nlamak istemiyorsan\u0131z, sadece paketi yerel olarak olu\u015fturmak i\u00e7in pack<\/code> komutunu kullan\u0131n:<\/p>\n\nnpx repo-context-packager pack\n <\/pre>\n<\/code><\/p>\n
Bu komut:<\/p>\n
\n- Git etiketini (
v1.0.0<\/code>) okuyacak.<\/li>\nnpm run build<\/code> komutunu \u00e7al\u0131\u015ft\u0131racak.<\/li>\npackage.json<\/code> dosyas\u0131n\u0131n s\u00fcr\u00fcm\u00fcn\u00fc okudu\u011fu etiketle g\u00fcncelleyecek (\u00f6rne\u011fin 1.0.0<\/code>).<\/li>\ndist<\/code> klas\u00f6r\u00fcndeki dosyalar\u0131 i\u00e7eren bir npm paketi (.tgz<\/code> dosyas\u0131) olu\u015fturacak. Bu dosyan\u0131n ad\u0131 my-awesome-library-1.0.0.tgz<\/code> gibi olacakt\u0131r.<\/li>\n<\/ol>\nE\u011fer publishCommand<\/code> tan\u0131ml\u0131ysa ve bir npm registry'ye yay\u0131nlamak istiyorsan\u0131z (bunun i\u00e7in NPM_TOKEN gibi kimlik bilgilerine ihtiyac\u0131n\u0131z olacakt\u0131r):<\/p>\n\nnpx repo-context-packager publish\n <\/pre>\n<\/code><\/p>\n
Bu ad\u0131mlar, repo-context-packager'\u0131n projenizin ba\u011flam\u0131n\u0131 nas\u0131l kulland\u0131\u011f\u0131n\u0131 ve paketleme ile s\u00fcr\u00fcmlendirme s\u00fcre\u00e7lerini nas\u0131l otomatikle\u015ftirdi\u011fini g\u00f6stermektedir. \u00d6zellikle versionFormat<\/code> fonksiyonu sayesinde, develop dallar\u0131ndan yap\u0131lan yay\u0131nlar i\u00e7in otomatik olarak 1.0.0-feature-branch.gabcdef<\/code> gibi \u00f6n-s\u00fcr\u00fcm etiketleri olu\u015fturulabilir. Bu, manuel m\u00fcdahaleyi ortadan kald\u0131r\u0131r ve s\u00fcr\u00fcm tutarl\u0131l\u0131\u011f\u0131n\u0131 garanti eder.<\/p>\n\nUzman \u0130pucu: publishCommand<\/code> i\u00e7indeki npm version --no-git-tag-version<\/code> komutu, package.json<\/code> dosyan\u0131zdaki s\u00fcr\u00fcm\u00fc g\u00fcncellemenizi sa\u011flar, ancak ek bir Git etiketi olu\u015fturmaz. Bu, repo-context-packager<\/code>'\u0131n belirledi\u011fi versiyonu kullan\u0131rken Git repository'nizin etiketleme yap\u0131s\u0131n\u0131 bozmadan ilerlemeniz i\u00e7in \u00f6nemlidir.<\/p>\n<\/p><\/div>\n