Dasturlash kitobi/13-QISM — NextJS55 daqiqa

13.10-bob: Deploy va Production

13-QISM — Next.js · 10-mavzu

1. Kirish va motivatsiya

Loyihangiz tayyor — chiroyli, tez, xavfsiz. Lekin u sizning kompyuteringizda (localhost:3000) — uni hech kim ko'ra olmaydi. Deploy (joylashtirish) — ilovangizni internetga chiqarish, real foydalanuvchilar ko'radigan, ishlata oladigan holatga keltirish. Bu — butun mehnatingizning maqsadi (kod yozish — vosita, deploy — natija; ishlamaydigan, hech kim ko'rmaydigan loyiha — faqat mashq). 10-QISM (DevOps)da biz Docker, CI/CD, server'ni umumiy o'rgandik — endi bularning Next.js'ga xos tomonini, va eng oson yo'lni ko'ramiz.

Next.js'ni deploy qilishning eng oson yo'li — Vercel (Next.js'ni yaratgan kompaniya — platforma Next.js uchun maxsus optimizatsiyalangan). Git'ga push qilasiz — Vercel avtomatik build qilib, dunyoga chiqaradi (bir necha daqiqa — bepul boshlash uchun). Lekin Vercel yagona emas: o'z serveringizda (Docker — 10.6), boshqa platformada (Railway, Render), yoki istalgan Node.js muhitda deploy qilsa bo'ladi. Har birining o'z afzalligi (Vercel — oson, server — nazorat, arzon). Deploy'dan keyin esa ish tugamaydi — production monitoring (xatolar, tezlik, foydalanuvchi) bilan ilovani kuzatish kerak (production'da nima bo'layotganini bilish — xato chiqsa darrov tuzatish).

Bu bob: deploy asoslari, Vercel'da deploy (eng oson — git), environment variables (production secret — xavfsiz), build jarayoni (next build — chiqishlar), boshqa platformalar (Docker — 10.6, o'z server), standalone output, domen va HTTPS, CI/CD (10.9 — Next.js bilan), preview deployments, monitoring (xatolar — Sentry, analytics, Speed Insights), va production checklist. Har mavzu to'liq, har kod misolida maqsad + izoh + "nima qiladi" bilan ochib beriladi.

O'xshatish: Deploy — bu restoranni ochish. Siz oylab oshpazlik o'rgandingiz, menyuni tayyorladingiz, taomlarni pishirdingiz (kod) — lekin agar restoranni ochmasangiz (deploy), hech kim taom yeya olmaydi (foydalanuvchi yo'q). Deploy — restoran eshigini och: (1) joy tanlash (Vercel — tayyor, jihozlangan bino; o'z server — bo'sh bino, o'zingiz jihozlaysiz); (2) manzil (domen — odamlar topadigan nom); (3) ruxsatnomalar (HTTPS — xavfsizlik sertifikati); (4) maxfiy retseptlar (environment variables — secret, oshxonada, mijoz ko'rmaydi); (5) ochilishdan keyin nazorat (monitoring — kamera, shikoyat daftari — nima yomon ketsa bilish). Restoranni ochish — bir martalik emas: doimiy kuzatish (taomlar sifati, mijoz fikri — monitoring), yangilanishlar (yangi taom — yangi deploy). Vercel — "tayyor restoran fpanshizasi" (kirdingiz, ochdingiz — Next.js uchun maxsus); o'z server — "o'z restoraningiz" (ko'proq ish, lekin to'liq nazorat).

Nega muhim?

Maqsad — deploy'siz loyiha hech kim ko'rmaydigan mashq (ishlatiladigan mahsulot bo'lishi uchun deploy shart).
Vercel — eng oson — Next.js uchun maxsus (git push dunyoga — daqiqalar ichida).
Production ≠ development — secret, optimizatsiya, monitoring (real foydalanuvchilar — boshqa talablar).
Doimiy kuzatish — monitoring bilan xato/sekinlik darrov topiladi (foydalanuvchi ketishdan oldin).

2. Nazariya — chuqur tushuntirish

2.1. Deploy asoslari va build jarayoni

text

  DEPLOY — kodni internetga chiqarish (development  production):

  DEVELOPMENT (npm run dev):
   kompyuteringizda (localhost:3000), hot reload, optimizatsiyasiz (tez yozish uchun)

  PRODUCTION (npm run build  npm start):
   optimizatsiyalangan (kichik, tez), real serverda, real foydalanuvchilar

  BUILD JARAYONI (next build):
  1. Kompilyatsiya (TypeScript  JS, JSX  JS)
  2. Optimizatsiya (bundle kichik, minify, tree-shaking — 13.7)
  3. Statik sahifalar generatsiya (SSG — 13.4)
  4. Server kodi tayyorlash (Server Components, Route Handlers)
   natija: .next/ papkasida optimizatsiyalangan ilova

  ┌────────────────────────────────────────────────────────────┐
  │ dev (localhost, hot reload)  build (optimizatsiya)        │
  │ production (real server, foydalanuvchilar)                  │
  └────────────────────────────────────────────────────────────┘

   Development (localhost, yozish uchun) ≠ Production (optimizatsiyalangan, real foydalanuvchi)
   next build — optimizatsiya (minify, statik, bundle); .next/ — tayyor ilova

Deploy asoslari va build jarayoni — development'dan production'ga o'tish. Ikki rejim: development (npm run dev) — kompyuteringizda (localhost:3000), hot reload (kod o'zgarsa darrov yangilanadi — tez yozish uchun), optimizatsiyasiz (tez build, lekin sekin ishlaydi — faqat rivojlanish uchun); production (npm run build npm start) — optimizatsiyalangan (kichik bundle, tez), real serverda, real foydalanuvchilar uchun. Build jarayoni (next build): (1) kompilyatsiya (TypeScript JavaScript, JSX JavaScript — brauzer/Node tushunadigan); (2) optimizatsiya (bundle kichik, minify — bo'shliq/izohlar olib tashlanadi, tree-shaking — ishlatilmagan kod olinadi — 13.7); (3) statik sahifalar generatsiya (SSG — build paytida HTML — 13.4); (4) server kodi tayyorlash (Server Components, Route Handlers — server uchun). Natija — .next/ papkasida optimizatsiyalangan, tayyor ilova (deploy qilinadigan). Ikki nuqta: (1) development (localhost, hot reload — yozish uchun) ≠ production (optimizatsiyalangan — real foydalanuvchi uchun) — bular boshqa muhit (har biri o'z maqsadiga); (2) next build — optimizatsiya (minify, statik, bundle — 13.7), .next/ — tayyor ilova. Deploy — bu .next/ (build natija)ni serverga qo'yib, ishga tushirish. Har deploy'dan oldin next build (lokalda yoki CI'da) muvaffaqiyatli bo'lishi shart (xato bo'lsa deploy bo'lmaydi — TypeScript xatolari, build xatolari shu yerda tutiladi). Bu — deploy'ning asosi (development build production).

2.2. Vercel'da deploy (eng oson)

text

  VERCEL — Next.js'ni deploy qilishning ENG OSON yo'li (Next.js yaratuvchilari):

  QADAMLAR (git-asosli — avtomatik):
  1. Kodni GitHub'ga push (git repo)
  2. vercel.com  "Import Project"  GitHub repo tanla
  3. Vercel avtomatik: framework aniqlaydi (Next.js), build qiladi, deploy qiladi
  4. Bir necha daqiqadan keyin: https://loyiham.vercel.app (jonli!)

  VERCEL AVTOMATIK QILADIGAN ISH:
   Build (next build — har push'da)
   Statik fayllarni CDN'ga (global — tez)
   Server (Server Components, Route Handlers — serverless/edge)
   HTTPS (avtomatik sertifikat)
   Preview deploy (har branch/PR — alohida URL — 2.9)

  GIT INTEGRATSIYA (eng kuchli):
  git push  Vercel avtomatik build + deploy (qo'lda hech narsa yo'q)

   Vercel — git push  avtomatik build + deploy (Next.js uchun maxsus — eng oson)
   HTTPS, CDN, preview — avtomatik; bepul boshlash (hobby) — keyin to'lovli (scale)

Vercel'da deploy (eng oson) — Next.js deploy'ning standart, eng oson yo'li. Vercel — Next.js'ni yaratgan kompaniya (platforma Next.js uchun maxsus optimizatsiyalangan — eng yaxshi integratsiya). Qadamlar (git-asosli — avtomatik): (1) kodni GitHub'ga push (git repo — 10.2); (2) vercel.comda "Import Project" GitHub repo tanlash; (3) Vercel avtomatik framework aniqlaydi (Next.js), build qiladi, deploy qiladi (sozlash deyarli kerak emas — Next.js'ni taniydi); (4) bir necha daqiqadan keyin — https://loyiham.vercel.app (jonli — internetda!). Vercel avtomatik qiladigan ish: (1) build (next build — har push'da); (2) statik fayllarni CDN'ga (global tarqalgan serverlar — foydalanuvchiga yaqin — tez — 13.7); (3) server kodini (Server Components, Route Handlers — serverless funksiya yoki edge — 13.6); (4) HTTPS (avtomatik sertifikat — 2.7); (5) preview deploy (har branch/PR uchun alohida URL — 2.9). Git integratsiya (eng kuchli): git push Vercel avtomatik build + deploy (qo'lda hech narsa qilmaysiz — push qildingiz, bir necha daqiqadan keyin jonli). Ikki nuqta: (1) Vercel — git push avtomatik build + deploy (Next.js uchun maxsus — eng oson, eng tez yo'l); (2) HTTPS, CDN, preview — avtomatik; bepul boshlash (hobby plan — shaxsiy loyiha uchun), keyin to'lovli (katta trafik, jamoa). Vercel — Next.js o'rganayotgan va kichik-o'rta loyiha uchun ideal (deploy haqida o'ylamasdan — kodga e'tibor). Lekin yagona emas (2.4 — boshqa platformalar). Yangi loyihani Vercel'da deploy qilib ko'rish — Next.js deploy'ni o'rganishnnng eng oson boshlanishi (git push, tamom).

2.3. Environment variables (production secret)

text

  ENVIRONMENT VARIABLES — sozlama va SECRET (har muhitda har xil — xavfsiz):

  IKKI TUR (Next.js):
  1. SERVER-only (secret — brauzerga CHIQMAYDI):
  DATABASE_URL=postgres://...      // DB ulanishi (maxfiy)
  AUTH_SECRET=...                  // token imzosi 13.9-bob
  STRIPE_SECRET_KEY=...            // to'lov (maxfiy)
   faqat server'da (Server Component, Route Handler, Server Action)

  2. PUBLIC (NEXT_PUBLIC_ prefiksi — brauzerga chiqadi):
  NEXT_PUBLIC_API_URL=https://api.sayt.com   //  public (brauzer ko'radi)
  NEXT_PUBLIC_ANALYTICS_ID=...
   brauzer'da ham (Client Component) — FAQAT public ma'lumot!

  MUHITLAR:
  .env.local (development — git'ga QO'SHMA — .gitignore)
  Vercel/server (production — platforma sozlamasida — xavfsiz)

   Server secret (DATABASE_URL, AUTH_SECRET) — NEXT_PUBLIC_ YO'Q (brauzerga chiqmasin)
   NEXT_PUBLIC_ — brauzerga chiqadi (FAQAT public; secret hech qachon NEXT_PUBLIC_)

Environment variables (production secret) — sozlama va secret'ni xavfsiz boshqarish. Environment variables (muhit o'zgaruvchilari) — koddan tashqaridagi sozlamalar (har muhitda — development/production — har xil bo'lishi mumkin). Next.js'da ikki tur: (1) server-only (secret — brauzerga chiqmaydi): DATABASE_URL (DB ulanishi — maxfiy), AUTH_SECRET (token imzosi — 13.9), STRIPE_SECRET_KEY (to'lov — maxfiy) — bular faqat server'da ishlaydi (Server Component, Route Handler, Server Action — 13.3: 2.9 — secret server'da); (2) public (NEXT_PUBLIC_ prefiksi bilan — brauzerga chiqadi): NEXT_PUBLIC_API_URL, NEXT_PUBLIC_ANALYTICS_ID — bular brauzer'da ham mavjud (Client Component'da) — shuning uchun faqat public ma'lumot bo'lishi shart (secret emas!). Muhitlar: .env.local (development — git'ga qo'shma — .gitignore'da — secret git'da bo'lmasligi kerak — 10.11), Vercel/server (production — platforma sozlamasida — xavfsiz saqlanadi). Ikki nuqta: (1) server secret (DATABASE_URL, AUTH_SECRET, to'lov kaliti) — NEXT_PUBLIC_ yo'q (brauzerga chiqmasin — agar NEXT_PUBLIC_ qo'ysangiz, secret brauzerda ko'rinadi — falokat); (2) NEXT_PUBLIC_ — brauzerga chiqadi (faqat public ma'lumot — API URL, analytics ID; secret hech qachon NEXT_PUBLIC_). Bu — eng keng, eng xavfli xato (secret'ni NEXT_PUBLIC_ bilan brauzerga chiqarib yuborish — DB paroli, to'lov kaliti commitda yoki brauzerda — jiddiy buzilish). Qoida: secret server'da (NEXT_PUBLIC_siz), faqat public ma'lumot NEXT_PUBLIC_ bilan. Production'da env'ni platformada (Vercel sozlamasi) saqlash (kodda yoki git'da emas — 10.11). Environment variables — deploy'ning xavfsizlik asosi.

2.4. Boshqa platformalar (Docker, o'z server)

text

  VERCEL'DAN TASHQARI — boshqa deploy variantlari (nazorat/narx uchun):

  1. DOCKER (10.6 — har joyda ishlaydi):
   Next.js'ni Docker konteynerga (har serverda — AWS, o'z VPS — bir xil)
   output: "standalone" (kichik konteyner — 2.5)

  2. O'Z SERVER (VPS — DigitalOcean, Hetzner — 10.4):
   Node.js o'rnatib, next build + next start (PM2 bilan — 10.5)
   Nginx reverse proxy 10.7-bob + SSL 10.8-bob

  3. BOSHQA PLATFORMALAR (Vercel kabi, lekin boshqa):
   Railway, Render, Netlify, AWS Amplify (git-asosli, oson)

  QAYSI QACHON:
   Tez, oson, Next.js'ga maxsus  Vercel 2.2-bob
   To'liq nazorat, arzon (katta trafik), o'z infra  Docker/VPS (10-QISM)
   O'rtacha (oson + arzonroq)  Railway/Render

   Vercel (oson, maxsus) | Docker/VPS (nazorat, arzon) | Railway/Render (o'rta)
   Next.js har joyda deploy bo'ladi (Node.js muhit) — Vercel maxsus, lekin majburiy emas

Boshqa platformalar (Docker, o'z server) — Vercel'dan tashqari variantlar. Vercel oson, lekin yagona emas — Next.js har joyda (Node.js muhit) deploy bo'ladi. Variantlar: (1) Docker (10.6 — har joyda bir xil ishlaydi): Next.js'ni Docker konteynerga joylashtirish (har serverda — AWS, o'z VPS, Kubernetes — bir xil ishlaydi — 10.6); buning uchun output: "standalone" (kichik konteyner — 2.5); (2) o'z server (VPS — DigitalOcean, Hetzner — 10.4): serverga Node.js o'rnatib, next build + next start (PM2 bilan — doimiy ishlash — 10.5), Nginx reverse proxy 10.7-bob + SSL sertifikat (10.8 — Let's Encrypt); (3) boshqa platformalar (Vercel kabi git-asosli, lekin boshqa): Railway, Render, Netlify, AWS Amplify (oson, ko'pincha arzonroq). Qaysi qachon: tez, oson, Next.js'ga maxsus optimizatsiya kerak Vercel 2.2-bob; to'liq nazorat, arzon (katta trafikda Vercel qimmat bo'lishi mumkin), o'z infratuzilma Docker/VPS (10-QISM); o'rtacha (oson + arzonroq) Railway/Render. Ikki nuqta: (1) Vercel (oson, Next.js'ga maxsus), Docker/VPS (nazorat, arzon — 10-QISM DevOps bilimlari), Railway/Render (o'rta — oson + arzonroq); (2) Next.js har joyda deploy bo'ladi (Node.js muhit — Vercel maxsus afzalliklar beradi — edge, optimizatsiya — lekin majburiy emas). Vendor lock-in (bir platformaga bog'lanib qolish)dan ehtiyot bo'lish kerak bo'lsa — Docker (har joyda ishlaydi — 10.6). Kichik loyiha/o'pganish Vercel (oson); katta/nazorat Docker/VPS (10-QISM bilimlari kerak). Tanlov — loyiha hajmi, byudjet, nazorat ehtiyojiga bog'liq. Next.js'ning moslashuvchanligi — har platformada ishlaydi (10-QISM DevOps — bu yerda qo'l keladi).

2.5. Standalone output va Docker

text

  STANDALONE OUTPUT — Next.js'ni MUSTAQIL, KICHIK paketga (Docker uchun ideal):

  // next.config.js
  module.exports = { output: "standalone" };
  //  build'da .next/standalone/ — faqat KERAKLI fayllar (node_modules'ning kerakli qismi)
  //  kichik Docker image (butun node_modules emas — faqat ishlatiladigan)

  DOCKERFILE (Next.js standalone — 10.6):
  FROM node:20-alpine AS builder
  WORKDIR /app
  COPY package*.json ./
  RUN npm ci
  COPY . .
  RUN npm run build                        # next build (standalone)

  FROM node:20-alpine AS runner
  WORKDIR /app
  COPY --from=builder /app/.next/standalone ./   # faqat kerakli (kichik)
  COPY --from=builder /app/.next/static ./.next/static
  COPY --from=builder /app/public ./public
  EXPOSE 3000
  CMD ["node", "server.js"]                 # standalone server

   output: "standalone" — mustaqil, kichik paket (Docker image kichik — faqat kerakli)
   Multi-stage Docker 10.6-bob — builder (build) + runner (faqat natija — kichik image)

Standalone output va Docker — Next.js'ni Docker'da samarali deploy qilish. output: "standalone" (next.config.js) — Next.js'ni mustaqil, kichik paketga to'playdi: build paytida .next/standalone/ papka yaratiladi (faqat kerakli fayllar — node_modulesning faqat ishlatiladigan qismi, butun emas). Bu Docker uchun ideal (kichik konteyner image — butun node_modules — yuzlab MB — emas, faqat kerakli — kichik, tez deploy). Dockerfile (Next.js standalone — multi-stage — 10.6): (1) builder bosqichi — npm ci (paketlar), npm run build (next build — standalone output); (2) runner bosqichi — faqat natijani ko'chiradi (COPY --from=builder /app/.next/standalone — standalone server, .next/static — statik fayllar, public — rasm/fayllar), va CMD ["node", "server.js"] (standalone server — Next.js avtomatik yaratgan). Multi-stage 10.6-bob — builder (build qiladi — og'ir, paketlar bilan) va runner (faqat natija — kichik image) — production image kichik (faqat ishlash uchun kerakli — build vositalari yo'q). Ikki nuqta: (1) output: "standalone" — mustaqil, kichik paket (Docker image kichik — faqat kerakli fayllar — tez deploy, kam joy); (2) multi-stage Docker 10.6-bob — builder (build) + runner (faqat natija — kichik image — production uchun optimal). Bu — Next.js'ni Docker'da deploy qilishning standart usuli (AWS, Kubernetes — 10.10, o'z server — har joyda ishlaydi — 10.6). Standalone'siz Docker image katta bo'lardi (butun node_modules) — standalone uni keskin kichraytiradi. 10-QISM (DevOps — Docker)dagi bilimlar bu yerda to'g'ridan ishlaydi (Next.js standalone — Docker'ning Next.js'ga moslashuvi). Docker — Vercel'dan tashqari eng keng deploy usuli (nazorat, portativlik).

2.6. CI/CD Next.js bilan

text

  CI/CD — avtomatik test + build + deploy (10.9 — Next.js bilan):

  // .github/workflows/deploy.yml (GitHub Actions — 10.9):
  name: Deploy
  on:
    push:
      branches: [main]
  jobs:
    build:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v4
        - uses: actions/setup-node@v4
          with: { node-version: 20 }
        - run: npm ci
        - run: npm run lint           #  kod sifati (ESLint)
        - run: npm run type-check     # TypeScript tekshir (tsc --noEmit)
        - run: npm test               # testlar 11.17-bob
        - run: npm run build          # build muvaffaqiyatlimi
        #  keyin deploy (Vercel avtomatik, yoki Docker push)

  CI/CD NIMA BERADI:
   Har push test/build tekshiriladi (buzuq kod production'ga BORMAYDI)
   Avtomatik deploy (qo'lda emas — xato kamayadi)
   Vercel — git push'da avtomatik CI/CD (o'rnatilgan)

   CI/CD — har push'da lint+type+test+build (buzuq kod o'tmaydi); keyin avtomatik deploy
   Vercel CI/CD o'rnatilgan (git push); o'z server — GitHub Actions (10.9)

CI/CD Next.js bilan — avtomatik test, build, deploy (10.9'ning Next.js'ga qo'llanishi). CI/CD (Continuous Integration / Continuous Deployment — 10.9) — har kod o'zgarishda avtomatik test, build, deploy. GitHub Actions (.github/workflows/deploy.yml — 10.9): on: push: branches: [main] (main'ga push'da ishlaydi), steps: checkout (kod), setup-node (Node.js 20), npm ci (paketlar), npm run lint (ESLint — kod sifati), npm run type-check (TypeScript — tsc --noEmit — tip xatolari), npm test (testlar — 11.17), npm run build (build muvaffaqiyatlimi). Keyin deploy (Vercel avtomatik qiladi, yoki Docker image push — 2.5). CI/CD nima beradi: (1) har push'da test/build tekshiriladi (buzuq kod — test yiqilgan, build xatosi, tip xatosi — production'ga bormaydi — sifat darvozasi — 10.9); (2) avtomatik deploy (qo'lda emas — inson xatosi kamayadi); (3) Vercel — git push'da avtomatik CI/CD (o'rnatilgan — alohida sozlash kerak emas — Vercel build + deploy qiladi). Ikki nuqta: (1) CI/CD — har push'da lint + type-check + test + build (buzuq kod o'tmaydi — production himoyalangan); keyin avtomatik deploy; (2) Vercel CI/CD o'rnatilgan (git push — avtomatik), o'z server uchun GitHub Actions (10.9 — qo'lda sozlash). Bu — professional deploy oqimi (har o'zgarish avtomatik tekshiriladi va chiqariladi — qo'lda "build qilib, serverga ko'chirish" emas — xavfsiz, tez, izchil). 10-QISM (DevOps — CI/CD)dagi bilimlar Next.js'da to'g'ridan ishlaydi. Vercel buni avtomatik qiladi (oson), o'z server uchun GitHub Actions (nazorat). CI/CD — sifatli, tez-tez deploy'ning asosi ("oyda bir marta katta deploy" o'rniga "har kun kichik, avtomatik tekshirilgan deploy").

2.7. Domen va HTTPS

text

  DOMEN va HTTPS — saytga manzil va xavfsizlik:

  DOMEN (loyiham.vercel.app  o'z domeningiz):
   domen sotib ol (Namecheap, GoDaddy — masalan myshop.uz)
   platformada (Vercel) domen qo'sh  DNS sozlash (A/CNAME record)
   myshop.uz sizning ilovangizga ishora qiladi

  HTTPS (shifrlangan ulanish — majburiy):
   Vercel: AVTOMATIK (Let's Encrypt sertifikat — bepul, avtomatik yangilanadi)
   o'z server: Certbot/Let's Encrypt 10.8-bob — Nginx bilan

  NEGA HTTPS MAJBURIY:
   Ma'lumot shifrlangan (parol, to'lov — o'rtada o'qilmaydi)
   Google SEO (HTTPS — reyting omili — 13.8)
   Brauzep "Xavfsiz emas" ogohlantirishi (HTTP — qo'rqitadi)
   Ba'zi xususiyatlar (Service Worker, geolokatsiya) faqat HTTPS

   Domen — o'z manzil (DNS bilan ilovaga ishora); HTTPS — shifrlangan (majburiy)
   Vercel HTTPS avtomatik; o'z server Let's Encrypt 10.8-bob — bepul SSL

Domen va HTTPS — saytga manzil va xavfsizlik. Domen — saytingizning nomi (loyiham.vercel.app o'rniga o'z nomingiz — myshop.uz): domenni sotib olish (Namecheap, GoDaddy, yoki .uz uchun mahalliy registrator), platformada (Vercel) domen qo'shish, DNS sozlash (A record yoki CNAME — domenni ilovangizga "ishora" qildirish). Natija: myshop.uz sizning ilovangizni ochadi (professional manzil — brendlash, ishonch). HTTPS (shifrlangan ulanish — https:// — majburiy): Vercel'da — avtomatik (Let's Encrypt sertifikati — bepul, avtomatik yangilanadi — siz hech narsa qilmaysiz); o'z serverda — Certbot/Let's Encrypt (10.8 — Nginx bilan — bepul SSL). Nega HTTPS majburiy: (1) ma'lumot shifrlangan (parol, to'lov, shaxsiy ma'lumot — internetda o'rtada o'qilmaydi — 10.8); (2) Google SEO (HTTPS — reyting omili — Google HTTP saytlarni pasaytiradi — 13.8); (3) brauzer "Xavfsiz emas" (Not Secure) ogohlantirishi (HTTP saytda — foydalanuvchini qo'rqitadi, ketadi); (4) ba'zi xususiyatlar (Service Worker, geolokatsiya, kamera) faqat HTTPS'da ishlaydi. Ikki nuqta: (1) domen — o'z manzil (DNS bilan ilovaga ishora — professional, brendlangan), HTTPS — shifrlangan ulanish (majburiy — xavfsizlik, SEO, ishonch); (2) Vercel HTTPS avtomatik (Let's Encrypt — bepul), o'z server Let's Encrypt (10.8 — Certbot bilan — bepul SSL). HTTPS bugun majburiy (HTTP — eskirgan, xavfli, Google jazolaydi) — barcha sayt HTTPS bo'lishi shart. Vercel buni avtomatik qiladi (oson), o'z serverda siz sozlaysiz (10.8 — lekin bepul, oson — Certbot). Domen + HTTPS — saytning "rasmiy" ko'rinishi (professional manzil + xavfsiz ulanish). Bu — deploy'ning yakuniy "yuz" qismi (foydalanuvchi ko'radigan manzil).

2.8. Monitoring va xatolar

text

  MONITORING — production'da nima bo'layotgani (xato, tezlik, foydalanuvchi):

  1. XATO KUZATUVI (error tracking — Sentry):
   production'dagi xatolarni avtomatik to'playdi (qaysi sahifa, qaysi foydalanuvchi, stack)
   siz darrov bilasiz (foydalanuvchi shikoyat qilishini kutmasdan)

  2. ANALYTICS (foydalanuvchi tahlili):
   necha foydalanuvchi, qaysi sahifa mashhur, qayerdan keldi
   Vercel Analytics, Google Analytics, Plausible (maxfiy)

  3. PERFORMANCE (Speed Insights — Core Web Vitals — 13.7):
   real foydalanuvchilar qanday tezlikda (LCP, CLS, INP — haqiqiy ma'lumot)
   Vercel Speed Insights, web-vitals

  4. LOGGING (server loglari):
   console.log/error  platforma loglari (Vercel logs, yoki o'z server — 10.x)

   Monitoring — production'ni KUZATISH (xato, tezlik, foydalanuvchi — bilish = tuzatish)
   Sentry (xato), Analytics (foydalanuvchi), Speed Insights (tezlik), logs (server)

Monitoring va xatolar — production'ni kuzatish (deploy'dan keyingi muhim ish). Deploy'dan keyin ish tugamaydi — ilovani kuzatish kerak (production'da nima bo'layotganini bilish — xato chiqsa, sekinlashca — darrov topib tuzatish — foydalanuvchi ketishdan oldin). To'rt asosij monitoring: (1) xato kuzatuvi (error tracking — Sentry kabi): production'dagi xatolarni avtomatik to'playdi (qaysi sahifa, qaysi foydalanuvchi, qaysi qatorda, to'liq stack trace) — siz darrov bilasiz (foydalanuvchi "ishlamayapti" deb shikoyat qilishini kutmasdan — proaktiv); (2) analytics (foydalanuvchi tahlili): necha foydalanuvchi tashrif buyurdi, qaysi sahifa mashhur, qayerdan keldi (Google, ijtimoiy) — Vercel Analytics, Google Analytics, Plausible (maxfiylikka hurmatli); (3) performance (Speed Insights — Core Web Vitals — 13.7): real foydalanuvchilar qanday tezlikda ko'rayapti (LCP, CLS, INP — haqiqiy ma'lumot — lab test emas, real foydalanuvchilar qurilmasida) — Vercel Speed Insights, web-vitals kutubxonasi; (4) logging (server loglari): console.log/console.error platforma loglari (Vercel logs, yoki o'z server loglari — 10.x — xato/hodisalarni yozish). Ikki nuqta: (1) monitoring — production'ni kuzatish (xato, tezlik, foydalanuvchi — bilish = tuzatish imkoni — kuzatuvsiz ilova "qora quti", muammolar yashirin); (2) Sentry (xato — darrov xabar), Analytics (foydalanuvchi — biznes qarorlar), Speed Insights (tezlik — Core Web Vitals), logs (server — debug). Bu — production'ning "sezgi organlari" (ilova qanday ishlayapt — real ma'lumot). Monitoring'siz deploy — "ko'r" deploy (xato chiqsa bilmaysiz — foydalanuvchi jim ketadi, sabab noaniq). Professional ilova doimo monitoring bilan (xato darrov topiladi, tezlik kuzatiladi, foydalanuvchi tushuniladi). Sentry (xato) va Speed Insights (tezlik) — eng muhim ikki (xato — buzilishni topish, tezlik — UX kuzatish). Deploy + monitoring — to'liq production hayoti (chiqarish + kuzatish).

2.9. Preview deployments va muhitlar

text

  PREVIEW DEPLOYMENTS — har branch/PR uchun alohida jonli URL (test uchun):

  GIT OQIMI (Vercel — avtomatik):
  main branch  production (myshop.uz — real foydalanuvchi)
  feature branch / PR  preview (myshop-abc123.vercel.app — test — 2.2)

  NEGA PREVIEW:
   Yangi xususiyatni REAL muhitda test (localhost emas — haqiqiy deploy)
   Jamoa/mijoz ko'radi (havola ulashib — "shu yangi dizayn — ko'ring")
   Production'ga qo'shishdan OLDIN tekshir (xato production'ga bormaydi)

  MUHITLAR (environment):
  development (localhost)  preview (test deploy)  production (real)
   har muhit o'z env (development DB, production DB — alohida)

  ┌────────────────────────────────────────────────────────────┐
  │ main  production (real) | branch/PR  preview (test URL)   │
  │  preview'da test, keyin main'ga merge  production         │
  └────────────────────────────────────────────────────────────┘

   Preview — har branch/PR jonli test URL (production'ga qo'shishdan oldin real test)
   Muhitlar: development  preview  production (har biri o'z env — alohida DB)

Preview deployments va muhitlar — xavfsiz, test bilan deploy. Preview deployments — har branch yoki PR (Pull Request) uchun alohida jonli URL (Vercel avtomatik). Git oqimi: main branch production (myshop.uz — real foydalanuvchi); feature branch yoki PR preview (myshop-abc123.vercel.app — test URL — 2.2). Nega preview: (1) yangi xususiyatni real muhitda test (localhost emas — haqiqiy deploy — production kabi muhit — masalan SSR, env, DB bilan); (2) jamoa yoki mijoz ko'radi (preview havolani ulashib — "shu yangi dizayn/xususiyat — ko'rib chiqing" — kod ko'rmasdan natijani); (3) production'ga qo'shishdan oldin tekshir (preview'da xato topilsa — production'ga bormaydi — xavfsiz). Muhitlar (environment): development (localhost — yozish) preview (test deploy — tekshir) production (real foydalanuvchi); har muhit o'z env (masalan development — test DB, production — real DB — alohida — 2.3 — production ma'lumotini buzmaslik). Ikki nuqta: (1) preview — har branch/PR uchun jonli test URL (production'ga qo'shishdan oldin real muhitda test — localhost'dan ishonchliroq); (2) muhitlar: development preview production (har biri o'z env — alohida DB — production ma'lumoti himoyalangan). Bu — professional, xavfsiz deploy oqimi (har o'zgarish avval preview'da test, keyin production'ga — to'g'ridan production'ga emas — xato xavfi kam). Vercel buni avtomatik qiladi (har PR — preview URL — jamoa ko'rib, tasdiqlab, keyin merge production). Bu git oqimi (10.2 — branch, PR) bilan birlashadi (feature branch preview review merge production). Preview deployments — zamonaviy, xavfsiz deploy madaniyatining asosi (test qilingan, ko'rilgan o'zgarish — production'ga).

2.10. Production checklist va best practices

text

  PRODUCTION CHECKLIST — deploy'dan oldin tekshir (jiddiy ro'yxat):

   XAVFSIZLIK:
    - Secret env'da (NEXT_PUBLIC_ emas — 2.3); .env git'da YO'Q
    - HTTPS 2.7-bob; auth himoya 13.9-bob; xavfsizlik header 13.6-bob
   PERFORMANCE:
    - next build muvaffaqiyatli; bundle tekshir 13.7-bob
    - Image/font optimizatsiya 13.7-bob; kesh to'g'ri 13.7-bob
   SEO:
    - Metadata har sahifa 13.8-bob; sitemap/robots; OG rasm
   ISHLASH:
    - Xatolar boshqaruvi (error.tsx — 13.2); 404 (not-found)
    - Environment variables to'liq (production'da)
   MONITORING:
    - Error tracking (Sentry — 2.8); analytics; logging

  BEST PRACTICES:
   Vercel (oson) yoki Docker (nazorat — 2.4)
   Preview'da test, keyin production 2.9-bob
   CI/CD (avtomatik test+build — 2.6)
   Monitoring (deploy'dan keyin kuzat — 2.8)
   Env muhitga qarab (dev/prod alohida — 2.3)

   Production checklist — xavfsizlik + performance + SEO + ishlash + monitoring (deploy'dan oldin)
   Best: Vercel/Docker + preview test + CI/CD + monitoring (professional deploy oqimi)

Production checklist va best practices — deploy'ning yakuniy, jiddiy tekshiruvi. Production checklist (deploy'dan oldin har biri tekshirilishi kerak): (1) xavfsizlik — secret env'da (NEXT_PUBLIC_ emas — 2.3), .env git'da yo'q 10.11-bob, HTTPS 2.7-bob, auth himoya 13.9-bob, xavfsizlik header (13.6: Misol 7); (2) performance — next build muvaffaqiyatli, bundle tekshir (13.7: Misol 7), image/font optimizatsiya 13.7-bob, kesh to'g'ri (13.7: Misol 9); (3) SEO — metadata har sahifa 13.8-bob, sitemap/robots, OG rasm; (4) ishlash — xatolar boshqaruvi (error.tsx — 13.2), 404 (not-found.tsx), environment variables to'liq (production'da barcha kerakli env bormi); (5) monitoring — error tracking (Sentry — 2.8), analytics, logging. Best practices: Vercel (oson) yoki Docker (nazorat — 2.4); preview'da test, keyin production 2.9-bob; CI/CD (avtomatik test + build — 2.6); monitoring (deploy'dan keyin kuzat — 2.8); env muhitga qarab (dev/prod alohida — 2.3). Ikki nuqta: (1) production checklist — xavfsizlik + performance + SEO + ishlash + monitoring (deploy'dan oldin har biri tekshiriladi — production "tirik" muhit, xato qimmat); (2) best: Vercel/Docker + preview test + CI/CD + monitoring (professional deploy oqimi — bir marta emas, doimiy). Bu — deploy'ning mas'uliyatli tomoni (production — real foydalanuvchilar, real ma'lumot — xato qimmat: ma'lumot yo'qotilishi, xavfsizlik buzilishi, foydalanuvchi ketishi). Checklist — bularni oldini oladi (har muhim jihat tekshirilgan). Professional dasturchi deploy'ni yengil olmaydi (checklist, test, monitoring — har deploy'da). Bu — 13-QISM (Next.js)ning amaliy yakuni: kod (13.1-13.9) + deploy 13.10-bob = ishlaydigan, ko'rinadigan, kuzatiladigan mahsulot. Deploy — texnik qadam emas, balki mas'uliyat (real foydalanuvchilarga xizmat — sifat, xavfsizlik, ishonchlilik). Production'ga chiqarish — boshlanish (monitoring, yangilanishlar — davom etadi), tugash emas.

2.11. Vercel platformasi chuqur (git integratsiya, preview, edge, env)

text

  VERCEL — Next.js uchun to'liq platforma (nafaqat hosting):

  GIT INTEGRATSIYA (avtomatik oqim):
  git push (main)    production deploy (myshop.uz)
  git push (branch)  preview deploy (alohida URL — 2.9)
  PR ochilsa         PR'ga preview havola avtomatik izoh (jamoa ko'radi)

  ENVIRONMENT (uch muhit — alohida env):
  Production    main branch (real DB, real kalitlar)
  Preview       branch/PR (test DB — production'ni buzmaslik)
  Development   vercel dev / .env.local (lokal)
   Vercel Dashboard  Settings  Environment Variables (har muhitga)

  EDGE NETWORK (CDN — global):
   statik fayllar + kesh dunyo bo'ylab (foydalanuvchiga yaqin server — tez)
   Edge Functions 2.13-bob — foydalanuvchiga eng yaqin joyda ishlaydi

  ANALYTICS + SPEED INSIGHTS (o'rnatilgan — Misol 6):
   trafik tahlili + real Core Web Vitals (bir buyruq bilan yoqiladi)

   Vercel — git push  build  deploy (production/preview avtomatik ajraladi)
   Uch muhit (production/preview/development) — har biri o'z env (secret alohida)

Vercel platformasi chuqur — Vercel faqat "hosting" emas, balki Next.js uchun to'liq deploy platformasi (git, muhitlar, edge, analytics — birga). Git integratsiya: main'ga push production deploy (myshop.uz), boshqa branch'ga push preview deploy (alohida URL — 2.9), PR ochilsa Vercel PR'ga preview havolani avtomatik izoh qilib qo'yadi (jamoa/mijoz kodni ochmasdan natijani ko'radi — 2.9). Environment (uch muhit — har biri o'z env): production (main — real DB, real to'lov kaliti), preview (branch/PR — test DB — production ma'lumotini buzmaslik), development (vercel dev yoki .env.local — lokal); env'lar Vercel Dashboard Settings Environment Variables'da (har muhitga alohida qiymat — masalan production DATABASE_URL real, preview DATABASE_URL test — 2.3). Edge network (CDN — global): statik fayllar va kesh dunyo bo'ylab tarqatiladi (foydalanuvchiga yaqin serverdan beriladi — kam kechikish, tez — 13.7); Edge Functions 2.13-bob foydalanuvchiga eng yaqin joyda ishlaydi. Analytics + Speed Insights (o'rnatilgan — Misol 6): trafik tahlili va real Core Web Vitals bir buyruq bilan yoqiladi (@vercel/analytics, @vercel/speed-insights). Ikki nuqta: (1) Vercel — git push build deploy, production va preview avtomatik ajraladi (main — production, boshqasi — preview); (2) uch muhit (production/preview/development) — har biri o'z env (secret alohida — production kaliti preview'ga chiqmaydi). Vercel'ning kuchi — bularning hammasi avtomatik (deploy, muhit ajratish, edge, preview — sozlashsiz ishlaydi). Bu Next.js o'rganuvchi va kichik-o'rta jamoa uchun eng tez yo'l (infratuzilmaga vaqt sarflamasdan mahsulotga e'tibor).

2.12. Boshqa platformalar batafsil (Netlify, Railway, Render, Amplify, Cloudflare)

text

  VERCEL'DAN TASHQARI git-asosli platformalar (har biri o'z afzalligi):

  NETLIFY        statik + serverless funksiya; Next.js adapter bilan (SSR ham)
  RAILWAY        to'liq server + DB (Postgres) bir joyda; oson, arzon boshlash
  RENDER         web service (Node) + boshqariladigan DB; PaaS, oddiy narx
  AWS AMPLIFY    AWS ekotizimi (S3, CloudFront, Lambda) — AWS'da bo'lsa qulay
  CLOUDFLARE PAGES  edge-birinchi (Workers runtime); global, arzon, tez edge

  TANLASH MEZONI:
   DB ham kerak, bir joyda  Railway / Render
   AWS infratuzilma bor  Amplify
   edge-birinchi, global tez  Cloudflare Pages
   maksimal Next.js integratsiya  Vercel (2.11)

   Barchasi git-asosli (push  build  deploy); farq — narx, runtime, DB, ekotizim
   Cloudflare Pages — edge runtime (Node API cheklangan — 2.13 tekshir)

Boshqa platformalar batafsil — Vercel yagona emas; har biri o'z afzalligi bilan git-asosli deploy beradi. Netlify — statik sayt va serverless funksiya (Next.js runtime/adapter bilan SSR ham ishlaydi); frontend jamoalar orasida keng tarqalgan. Railway — ilova va ma'lumotlar bazasi (Postgres, Redis) bir joyda (bir loyihada server + DB — qulay, arzon boshlash — kichik loyiha uchun ideal). Render — web service (Node) va boshqariladigan DB beruvchi PaaS (oddiy, tushunarli narx — Heroku o'rnini bosuvchi sifatida keng ishlatiladi). AWS Amplify — AWS ekotizimida (S3, CloudFront CDN, Lambda) — agar infratuzilmangiz allaqachon AWS'da bo'lsa qulay (bir hisob, bir ekotizim). Cloudflare Pages — edge-birinchi (Cloudflare Workers runtime) — global, arzon, edge'da juda tez, lekin runtime cheklangan (2.13 — Node.js API'ning bir qismi yo'q — moslikni tekshirish kerak). Tanlash mezoni: DB ham kerak, bir joyda boshqarish Railway/Render; AWS infratuzilma bor Amplify; edge-birinchi, global tezlik Cloudflare Pages; maksimal Next.js integratsiya, eng oson Vercel 2.11-bob. Ikki nuqta: (1) barchasi git-asosli (push build deploy — Vercel bilan bir xil oqim), farqi — narx, runtime, birlashtirilgan DB, ekotizim; (2) Cloudflare Pages edge runtime (Node.js API cheklangan — 2.13'ni tekshirish shart — ba'zi kutubxonalar ishlamasligi mumkin). Xulosa: Next.js har joyda deploy bo'ladi (Node.js muhit — 2.4); platforma tanlovi loyiha ehtiyoji (DB, byudjet, ekotizim, edge)ga bog'liq. Vercel — eng oson boshlanish, lekin vendor lock-in'dan qochish kerak bo'lsa Docker 2.5-bob yoki boshqa platforma.

2.13. Runtime (Node vs Edge) va ISR production'da

text

  RUNTIME — kod qayerda ishlaydi (deploy'da muhim):

  NODE RUNTIME (standart):
   to'liq Node.js API (fs, crypto, DB kutubxonalari)
   serverless funksiya (Vercel) yoki doimiy server (self-host — next start)

  EDGE RUNTIME (foydalanuvchiga yaqin, tez sovuq start):
  export const runtime = "edge";   // route/sahifada
   CDN chetida ishlaydi (past kechikish), lekin Node API CHEKLANGAN
   og'ir DB drayver, fs — ishlamasligi mumkin (yengil ishlar uchun)

  ISR (Incremental Static Regeneration — production kesh):
  export const revalidate = 3600;  // har soatda qayta generatsiya (statik + yangi)
   sahifa statik (tez), lekin belgilangan vaqtda fon'da yangilanadi

  ON-DEMAND REVALIDATION (o'zgarganda darrov yangilash):
  revalidatePath("/blog");         // ma'lumot o'zgarsa keshni tozala 13.4-bob
  revalidateTag("posts");

   Node (to'liq API) vs Edge (tez, cheklangan API) — deploy'da ongli tanlov
   ISR — statik tezlik + yangi ma'lumot (revalidate); on-demand — o'zgarganda tozalash

Runtime va ISR production'da — deploy'da kod qayerda va qanday keshlangan holda ishlashi muhim. Node runtime (standart) — to'liq Node.js API (fs, crypto, og'ir DB kutubxonalari — Prisma va boshqa) ishlaydi; Vercel'da serverless funksiya sifatida, self-host'da doimiy server (next start — 2.4) sifatida. Edge runtime (export const runtime = "edge") — kod CDN chetida (foydalanuvchiga eng yaqin joyda) ishlaydi — past kechikish, tez sovuq start (cold start), lekin Node.js API cheklangan (fs yo'q, og'ir DB drayverlar ishlamasligi mumkin — faqat yengil, tez ishlar uchun — masalan auth tekshiruvi, geolokatsiya, A/B test). ISR (Incremental Static Regeneration — 13.4) production'da kesh strategiyasi: export const revalidate = 3600 — sahifa statik (tez — CDN'dan), lekin belgilangan vaqtda (masalan har soatda) fon'da qayta generatsiya qilinadi (statik tezlik + nisbatan yangi ma'lumot — ikkalasi). On-demand revalidation — ma'lumot o'zgarganda darrov keshni tozalash: revalidatePath("/blog") yoki revalidateTag("posts") (masalan admin yangi post qo'shsa — o'sha sahifa keshi tozalanadi, keyingi so'rovda yangi HTML — 13.4). Ikki nuqta: (1) Node (to'liq API — og'ir ishlar) vs Edge (tez, past kechikish, cheklangan API — yengil ishlar) — deploy'da ongli tanlov (edge'da og'ir DB ishlatib bo'lmaydi); (2) ISR — statik tezlik + yangi ma'lumot (revalidate — vaqt bo'yicha), on-demand — o'zgarganda darrov tozalash (revalidatePath/revalidateTag). Production'da kesh — muvozanat: to'liq statik (eng tez, lekin eskiradi) har so'rovda dinamik (doim yangi, lekin sekin); ISR ikkalasining o'rtasi (tez + yetarlicha yangi). CDN kesh header'lari (Cache-Control — 2.14) bilan birga — production tezligining asosi. Muhim: edge runtime hamma platformada ishlamaydi (Vercel — ha, self-host Node server — yo'q; Cloudflare — edge-birinchi — 2.12) — deploy platformasiga qarab tanlash.

2.14. Self-host chuqur (PM2, Nginx, kesh header, image, DB migratsiya, rollback)

text

  SELF-HOST — o'z serveringizda to'liq boshqaruv (Vercel'siz — 2.4):

  1. ISHGA TUSHIRISH (PM2 — doimiy — 10.5):
  next build && pm2 start "npm start" --name myshop   # qayta ishga tushadi, log
  pm2 startup && pm2 save                              # server qayta yoqilsa avtomatik

  2. NGINX REVERSE PROXY 10.7-bob + kesh header:
  location / { proxy_pass http://localhost:3000; }     # Nginx  Next.js (3000)
  location /_next/static { expires 1y; }               # statik — uzoq kesh (immutable)

  3. IMAGE OPTIMIZATSIYA (self-host — 8.21 / 10.24):
   Vercel'da avtomatik; self-host'da sharp o'rnatiladi (npm i sharp)
   yoki tashqi loader (Cloudinary) — server yukini kamaytirish

  4. DB MIGRATSIYA (deploy'da — 14-QISM):
  npx prisma migrate deploy   # deploy oldidan/vaqtida sxemani yangilash

  5. ROLLBACK (xato deploy — orqaga):
   Vercel: bir bosishda oldingi deploy'ga qaytish (Dashboard)
   self-host: oldingi git tegi/image'ga qaytib qayta deploy

   Self-host — PM2 (doimiy) + Nginx (proxy/SSL/kesh) + sharp (image) + migratsiya
   Rollback rejasi bo'lsin (xato deploy  tez orqaga — Vercel bir bosish, self-host git/image)

Self-host chuqur — o'z serveringizda deploy'ning barcha bo'g'inlari (Vercel avtomatik qiladigan ishlarni siz sozlaysiz — 2.4). (1) Ishga tushirish (PM2 — 10.5): next build (production build), keyin pm2 start "npm start" --name myshop — PM2 jarayonni doimiy ushlaydi (yiqilsa qayta ishga tushiradi, loglarni yig'adi), pm2 startup && pm2 save — server qayta yoqilsa ilova avtomatik ishga tushadi (next start to'g'ridan ishlatilsa — server o'chsa ilova o'chadi — PM2 bu muammoni yechadi). (2) Nginx reverse proxy 10.7-bob: Nginx tashqi so'rovlarni (80/443-port) ichki Next.js serveriga (localhost:3000) uzatadi (proxy_pass), SSL'ni tugatadi 10.8-bob, va statik fayllarga kesh header qo'yadi (/_next/static — expires 1y — bu fayllar o'zgarmas/immutable, uzoq keshlansa bo'ladi — 2.13). (3) Image optimizatsiya (self-host — 8.21/10.24): Vercel'da avtomatik, self-host'da sharp o'rnatiladi (npm i sharp — next/image uni ishlatib rasmlarni optimizatsiya qiladi), yoki tashqi loader (Cloudinary — server yukini kamaytiradi, katta trafikda foydali). (4) DB migratsiya (deploy'da — 14-QISM): npx prisma migrate deploy — deploy oldidan yoki vaqtida ma'lumotlar bazasi sxemasini yangilash (yangi jadval/ustun — kod bilan mos bo'lishi shart; migratsiyasiz kod yangi ustunni so'raydi, DB'da yo'q — xato). (5) Rollback (xato deploy — orqaga qaytish): Vercel — Dashboard'da bir bosishda oldingi deploy'ga qaytish; self-host — oldingi git tegi (tag) yoki Docker image'ga qaytib qayta deploy. Ikki nuqta: (1) self-host — PM2 (doimiy ishlash) + Nginx (proxy/SSL/kesh) + sharp (image) + migratsiya (DB) — Vercel avtomatik qiladigan ishlarni siz qo'lda sozlaysiz; (2) rollback rejasi bo'lsin — xato deploy chiqsa tez orqaga qaytish (Vercel bir bosish, self-host git tag/image) — production'da xato muqarrar, tez tiklanish muhim. Self-host — ko'proq nazorat va arzonlik (katta trafik), lekin ko'proq mas'uliyat (bu bo'g'inlarni o'zingiz boqasiz — 10-QISM DevOps bilimlari shu yerda ishlaydi).

2.15. Xavfsizlik header'lari va performance budget (production)

text

  PRODUCTION XAVFSIZLIK + BUDJET:

  XAVFSIZLIK HEADER'LARI (next.config yoki middleware — 13.6):
  Content-Security-Policy       qaysi manbadan skript/stil (XSS himoya)
  Strict-Transport-Security     doim HTTPS (HSTS — brauzer majburlaydi)
  X-Frame-Options: DENY         clickjacking himoya (iframe'ga solmaslik)
  X-Content-Type-Options: nosniff  MIME hidini o'chirish
  Referrer-Policy               referrer sizib chiqishini cheklash

  PERFORMANCE BUDGET (chegara — 13.7):
   First Load JS chegarasi (masalan < 130 kB) — oshsa CI ogohlantiradi
   bundle analyzer + CI tekshiruvi (og'ir paket qo'shilsa — bloklaydi)

   Xavfsizlik header'lari — production'da MAJBURIY (CSP, HSTS eng muhim)
   Performance budget — bundle o'smasin (chegara belgila, CI'da tekshir — 2.6)

Xavfsizlik header'lari va performance budget — production'ning himoya va tezlik chegaralari. Xavfsizlik header'lari (next.config.js headers() yoki middleware — 13.6: Misol 2, 7): (1) Content-Security-Policy (CSP) — brauzerga qaysi manbadan skript/stil/rasm yuklashga ruxsat borligini aytadi (ruxsatsiz skript ishlamaydi — XSS hujumidan asosiy himoya — 14-QISM); (2) Strict-Transport-Security (HSTS) — brauzerni doim HTTPS'da ulanishga majburlaydi (HTTP'ga tushmaydi — 2.7); (3) X-Frame-Options: DENY — saytingizni iframe'ga solishga ruxsat bermaydi (clickjacking himoya); (4) X-Content-Type-Options: nosniff — brauzer MIME turini "hidlamaydi" (faqat e'lon qilinganini ishlatadi); (5) Referrer-Policy — boshqa saytga o'tganda qancha referrer ma'lumoti yuborilishini cheklaydi. Performance budget 13.7-bob — bundle hajmiga chegara belgilash: masalan First Load JS < 130 kB — agar yangi kod bu chegaradan oshirsa, CI 2.6-bob ogohlantiradi yoki bloklaydi (bundle analyzer natijasi CI'da tekshiriladi — og'ir kutubxona sezdirmay qo'shilib qolmaydi). Ikki nuqta: (1) xavfsizlik header'lari production'da majburiy (CSP va HSTS eng muhim — XSS va HTTP'dan himoya — 14-QISM); (2) performance budget — bundle o'smasligi uchun chegara (CI'da tekshir — 2.6 — "sekinlashuv" asta-sekin sezilmay kelib qolmasin). Bu ikkisi — production'ni doimiy himoyalash (xavfsizlik — hujumdan, budjet — sekinlashuvdan). Header'larni bir joyda (next.config yoki middleware — markaziy) belgilash, budjetni CI'ga bog'lash — professional production sozlamasining qismi (2.10 checklist bilan birga).

3. Sintaksis — tez ma'lumotnoma

text

BUILD 2.1-bob:       next build (optimizatsiya)  next start (production server)
VERCEL 2.2-bob:      git push  avtomatik build + deploy
ENV SERVER 2.3-bob:  DATABASE_URL=... (secret — server-only)
ENV PUBLIC 2.3-bob:  NEXT_PUBLIC_API_URL=... (brauzerga chiqadi — faqat public)
STANDALONE 2.5-bob:  next.config.js  output: "standalone" (Docker — kichik)
CI/CD 2.6-bob:       .github/workflows  lint + type-check + test + build
DOMEN 2.7-bob:       platformada domen + DNS (A/CNAME); HTTPS avtomatik (Vercel)
MONITORING 2.8-bob:  Sentry (xato) | Analytics | Speed Insights (Core Web Vitals)
PREVIEW 2.9-bob:     branch/PR  preview URL; main  production
RUNTIME 2.13-bob:    export const runtime = "edge" (tez, cheklangan) | node (to'liq)
ISR 2.13-bob:        export const revalidate = 3600 | revalidatePath("/blog")
SELF-HOST 2.14-bob:  pm2 start "npm start" | Nginx proxy_pass localhost:3000
MIGRATSIYA 2.14-bob: npx prisma migrate deploy (deploy'da DB sxema)
HEADER 2.15-bob:     next.config headers()  CSP, HSTS, X-Frame-Options

4. Batafsil kod namunalari

Har misol: Maqsad + izohli kod + "Bu kod nima qiladi".

Misol 1 — Environment variables (server va public — 2.3)

Maqsad: Secret va public env'ni to'g'ri ajratish — secret server'da, public NEXT_PUBLIC_ bilan. Bu deploy xavfsizligining eng muhim qoidasi.

bash

# .env.local (development — git'ga QO'SHMA — .gitignore'da!)

# SERVER-ONLY (secret — brauzerga CHIQMAYDI):
DATABASE_URL="postgresql://user:password@localhost:5432/mydb"
AUTH_SECRET="uzun-tasodifiy-satr-npx-auth-secret"
STRIPE_SECRET_KEY="sk_live_..."
RESEND_API_KEY="re_..."

# PUBLIC (NEXT_PUBLIC_ — brauzerga chiqadi — FAQAT public!):
NEXT_PUBLIC_APP_URL="https://myshop.uz"
NEXT_PUBLIC_ANALYTICS_ID="G-XXXXXXX"

tsx

// Ishlatish:
// SERVER (Server Component, Route Handler, Server Action):
const db = process.env.DATABASE_URL;          //  server'da (secret)
const stripeKey = process.env.STRIPE_SECRET_KEY;  //  server'da

// CLIENT (Client Component):
const appUrl = process.env.NEXT_PUBLIC_APP_URL;   //  public (brauzer ham)
// const secret = process.env.STRIPE_SECRET_KEY;  //  client'da undefined (secret chiqmaydi)

Bu kod nima qiladi: Bu — environment variables'ni to'g'ri ajratish (deploy xavfsizligining eng muhim qoidasi — 2.3). .env.local faylda (development — git'ga qo'shilmaydi — .gitignore'da — secret git tarixida bo'lmasligi kerak — 10.11) ikki tur env: (1) server-only (secret — NEXT_PUBLIC_ siz): DATABASE_URL (DB ulanishi — parol bilan), AUTH_SECRET (token imzosi — 13.9), STRIPE_SECRET_KEY (to'lov kaliti), RESEND_API_KEY (email) — bular faqat server'da ishlaydi (Server Component, Route Handler, Server Action — process.env.DATABASE_URL — brauzerga chiqmaydi); (2) public (NEXT_PUBLIC_ prefiksi bilan): NEXT_PUBLIC_APP_URL, NEXT_PUBLIC_ANALYTICS_ID — bular brauzerga chiqadi (Client Component'da ham process.env.NEXT_PUBLIC_APP_URL ishlaydi). Ishlatish farqi: server'da har ikki tur ishlaydi (DATABASE_URL, NEXT_PUBLIC_APP_URL); client'da faqat NEXT_PUBLIC_ (process.env.STRIPE_SECRET_KEY client'da undefined — secret chiqmaydi — Next.js uni brauzerga yubormaydi). Nega bu muhim: agar secret'ni NEXT_PUBLIC_ bilan belgilasangiz (masalan NEXT_PUBLIC_STRIPE_SECRET), u brauzerga chiqadi — har kim brauzer devtools'da ko'radi — to'lov kaliti o'g'irlanadi (falokat). Qoida: secret (DB, auth, to'lov, API kalit) — NEXT_PUBLIC_siz (server-only); public (URL, analytics ID — maxfiy emas) — NEXT_PUBLIC_ bilan. Production'da bu env'lar platformada (Vercel sozlamasi yoki server) saqlanadi (.env.local faqat development — git'da yo'q). Bu — deploy'ning eng keng, eng xavfli xatosidan (secret sizib ketishidan) himoya. Har env qo'shganda savol: "bu brauzerga chiqsa bo'ladimi?" — yo'q server-only, ha NEXT_PUBLIC_.

Misol 2 — next.config.js (production sozlama — 2.5)

Maqsad: Next.js production sozlamasini to'g'ri qilish — standalone output, image domenlari, xavfsizlik. Bu deploy uchun asosiy konfiguratsiya.

tsx

// next.config.js — production konfiguratsiya
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: "standalone",                   // Docker uchun kichik paket (2.5)

  images: {
    // next/image uchun ruxsat etilgan tashqi domenlar 13.7-bob:
    remotePatterns: [
      { protocol: "https", hostname: "cdn.myshop.uz" },
      { protocol: "https", hostname: "res.cloudinary.com" },
    ],
  },

  // Production'da console.log'larni olib tashlash (ixtiyoriy):
  compiler: {
    removeConsole: process.env.NODE_ENV === "production" ? { exclude: ["error"] } : false,
  },

  // Xavfsizlik header'lari (agar middleware'da emas — 13.6):
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          { key: "X-Frame-Options", value: "DENY" },
          { key: "X-Content-Type-Options", value: "nosniff" },
        ],
      },
    ];
  },
};

module.exports = nextConfig;

Bu kod nima qiladi: Bu — Next.js production konfiguratsiyasi (deploy uchun asosiy sozlamalar — 2.5). next.config.jsda: (1) output: "standalone" — Docker uchun kichik, mustaqil paket (2.5 — .next/standalone/ — faqat kerakli fayllar — Docker image kichik); (2) images.remotePatterns — next/image 13.7-bob uchun ruxsat etilgan tashqi rasm domenlari (masalan cdn.myshop.uz, Cloudinary) — Next.js xavfsizlik uchun faqat ruxsat etilgan domenlardan rasm optimizatsiya qiladi (har joydan emas — aks holda yomon niyatli kishi sizning image optimizatsiyangizni suiiste'mol qilishi mumkin); (3) compiler.removeConsole — production'da console.log'larni olib tashlaydi (exclude: ["error"] — console.error qoladi — xatolar kerak) — debug log'lar production'da keraksiz (ixtiyoriy optimizatsiya); (4) headers — xavfsizlik header'lari (X-Frame-Options, X-Content-Type-Options — 13.6: Misol 7 — agar middleware'da qilmagan bo'lsangiz, bu yerda — markaziy). NODE_ENV === "production" — Next.js avtomatik belgilaydigan muhit (development/production — shartli sozlama). Bu konfiguratsiya — har production Next.js loyihasining asosi (standalone — Docker, image domenlari — rasm optimizatsiya, xavfsizlik header — himoya). next.config.js — Next.js'ning "boshqaruv markazi" (build, image, header, redirect, va boshqa sozlamalar). Production'ga deploy qilishdan oldin bu fayl to'g'ri sozlangan bo'lishi kerak (ayniqsa image domenlari — aks holda tashqi rasmlar ishlamaydi — keng xato). Har loyiha o'z ehtiyojiga qarab sozlaydi (standalone faqat Docker uchun, image domenlari — qaysi CDN ishlatsangiz). Bu — deploy'ning texnik tayyorgarlik qismi (konfiguratsiya to'g'ri bo'lsa — deploy silliq).

Misol 3 — Dockerfile (standalone — 2.5)

Maqsad: Next.js'ni Docker'da deploy qilish — multi-stage, standalone, kichik image. Bu Vercel'dan tashqari, har joyda ishlaydigan deploy.

dockerfile

# Dockerfile — Next.js production (multi-stage — 10.6)

# 1-BOSQICH: builder (build qiladi — og'ir, paketlar bilan):
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci                              # paketlar (aniq versiyalar — lock'dan)
COPY . .
RUN npm run build                       # next build (standalone — 2.5)

# 2-BOSQICH: runner (faqat natija — kichik image):
FROM node:20-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
# Faqat kerakli fayllarni ko'chir (standalone — kichik):
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]               # standalone server (Next.js yaratgan)

bash

# Build va ishga tushirish:
# docker build -t myshop .
# docker run -p 3000:3000 --env-file .env.production myshop

Bu kod nima qiladi: Bu — Next.js'ni Docker'da deploy qilish (multi-stage, standalone — 2.5, 10.6). Multi-stage (ikki bosqich — 10.6): (1) builder — Next.js'ni build qiladi: node:20-alpine (yengil Node.js image), npm ci (paketlarni aniq versiyada — package-lock.json'dan — izchil), npm run build (next build — standalone output — 2.5); (2) runner — faqat natijani oladi (kichik production image): ENV NODE_ENV=production (production rejimi), keyin faqat kerakli fayllarni ko'chiradi — .next/standalone (mustaqil server — 2.5), .next/static (statik fayllar), public (rasm/fayllar), va CMD ["node", "server.js"] (standalone server — Next.js avtomatik yaratgan — npm start emas, to'g'ridan node). Nega multi-stage: builder bosqichi og'ir (barcha paketlar, build vositalari — yuzlab MB), lekin runner faqat natija (standalone — kichik) — production image kichik (faqat ishlash uchun kerakli — build vositalari, dev paketlar yo'q — tez deploy, kam joy, kam hujum yuzasi). Build va ishga tushirish: docker build -t myshop . (image yasash), docker run -p 3000:3000 --env-file .env.production myshop (ishga tushirish — port 3000, env fayldan — 2.3 — secret env). Bu — Next.js'ni har joyda (AWS, Kubernetes — 10.10, o'z VPS, Railway) deploy qilishning standart usuli (Docker — portativ — 10.6 — bir image har joyda bir xil). Vercel'dan farqli — to'liq nazorat (qaysi server, qancha resurs), arzon (katta trafikda), lekin ko'proq ish (Dockerfile, server, monitoring — siz qilasiz). 10-QISM (DevOps — Docker)dagi bilimlar bu yerda to'g'ridan ishlaydi (Next.js standalone — Docker'ning Next.js'ga moslashuvi). Bu — Vercel'dan tashqari eng keng deploy yo'li (nazorat va portativlik kerak bo'lganda).

Misol 4 — GitHub Actions CI/CD (2.6)

Maqsad: Har push'da avtomatik test va build — CI pipeline. Bu buzuq kodning production'ga borishini oldini oladi.

yaml

# .github/workflows/ci.yml — CI pipeline (10.9)
name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: "npm"                  # paketlarni keshla (tezroq)

      - run: npm ci                     # paketlar (aniq versiya)
      - run: npm run lint               # ESLint (kod sifati)
      - run: npm run type-check         # tsc --noEmit (TypeScript)
      - run: npm test                   # testlar (11.17)
      - run: npm run build              #  build muvaffaqiyatlimi (oxirgi darvoza)
        env:
          # Build uchun kerakli env (secret — GitHub Secrets'dan):
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          AUTH_SECRET: ${{ secrets.AUTH_SECRET }}

Bu kod nima qiladi: Bu — CI pipeline (har push'da avtomatik tekshiruv — 2.6, 10.9). GitHub Actions (.github/workflows/ci.yml): on: push: [main, develop] va pull_request: [main] (main/develop'ga push'da va main'ga PR'da ishlaydi — har o'zgarish tekshiriladi). test job (qadamlar): (1) checkout (kodni ol), setup-node (Node.js 20, cache: "npm" — paketlarni keshlab tezroq); (2) npm ci (paketlar — aniq versiya — package-lock.json'dan); (3) npm run lint (ESLint — kod sifati, uslub); (4) npm run type-check (tsc --noEmit — TypeScript tip xatolari — 11.14); (5) npm test (testlar — 11.17 — funksionallik); (6) npm run build (build muvaffaqiyatlimi — oxirgi darvoza — agar build yiqilsa, kod production'ga bormaydi). Build uchun kerakli env (DATABASE_URL, AUTH_SECRET) GitHub Secrets'dan (${{ secrets.DATABASE_URL }} — secret git'da emas, GitHub'ning xavfsiz saqlovida — 2.3, 10.11). Nega CI: har push'da bu zanjir (lint type test build) avtomatik ishlaydi — agar birortasi yiqilsa (ESLint xatosi, tip xatosi, test yiqilgan, build buzuq), pipeline to'xtaydi (qizil belgi) va kod birlashtirilmaydi/deploy bo'lmaydi (sifat darvozasi — 10.9). Ya'ni buzuq kod hech qachon production'ga bormaydi (avtomatik himoya — inson "tekshirishni unutdi" muammosi yo'q). PR'da bu ishlasa — kod ko'riluvchi (reviewer) "CI o'tdimi?" ni ko'rib, keyin merge qiladi (yashil belgi — xavfsiz). Bu — professional jamoa deploy oqimining asosi (har o'zgarish avtomatik tekshiriladi — sifat kafolatlangan). Vercel buni qisman avtomatik qiladi (build), lekin to'liq CI (lint, type, test) GitHub Actions bilan (yoki Vercel'ning o'z CI bilan). CI/CD — tez-tez, ishonchli deploy'ning poydevori (10.9 — DevOps).

Misol 5 — Sentry error tracking (2.8)

Maqsad: Production xatolarni avtomatik to'plash — Sentry bilan. Bu foydalanuvchi shikoyat qilishini kutmasdan xatolarni topadi.

tsx

// sentry.client.config.ts — Sentry sozlash (client xatolari)
import * as Sentry from "@sentry/nextjs";

Sentry.init({
  dsn: process.env.NEXT_PUBLIC_SENTRY_DSN,   // Sentry loyiha manzili (public — 2.3)
  tracesSampleRate: 1.0,                       // performance kuzatuvi (1.0 = 100%)
  replaysOnErrorSampleRate: 1.0,               // xato bo'lganda — sessiya yozuvi
});

// app/global-error.tsx — global xato (Sentry'ga yuboriladi):
"use client";
import * as Sentry from "@sentry/nextjs";
import { useEffect } from "react";

export default function GlobalError({ error }: { error: Error }) {
  useEffect(() => {
    Sentry.captureException(error);   //  xato'ni Sentry'ga yubor (avtomatik to'planadi)
  }, [error]);

  return (
    <html>
      <body>
        <h2>Nimadir noto'g'ri ketdi</h2>
        <p>Xatolik qayd etildi, tez orada tuzatamiz.</p>
      </body>
    </html>
  );
}

Bu kod nima qiladi: Bu — production xato kuzatuvi (Sentry — 2.8). Sentry — production'dagi xatolarni avtomatik to'plovchi xizmat. Sozlash (sentry.client.config.ts): Sentry.init({ dsn, tracesSampleRate, replaysOnErrorSampleRate }) — dsn (Sentry loyiha manzili — qaerga xato yuborilsin — NEXT_PUBLIC_ chunki client'da ham — 2.3), tracesSampleRate (performance kuzatuvi — qancha so'rov kuzatilsin), replaysOnErrorSampleRate (xato bo'lganda foydalanuvchi sessiyasini yozish — xato qanday yuz berganini ko'rish — "video" kabi). global-error.tsx (13.2: 2.5 — error.tsx'ning global versiyasi — butun ilova qulasa): useEffectda Sentry.captureException(error) — xato'ni Sentry'ga yuboradi (avtomatik to'planadi — qaysi sahifa, qaysi foydalanuvchi, qaysi qatorda, brauzer, qurilma — to'liq kontekst), va foydalanuvchiga tushunarli xabar ("Nimadir noto'g'ri ketdi — tez orada tuzatamiz" — oq ekran emas). Nega Sentry (yoki shunga o'xshash): production'da xato chiqsa (masalan ba'zi foydalanuvchida — ma'lum brauzer, ma'lum ma'lumot bilan), siz uni bilmaysiz (foydalanuvchi jim ketadi — shikoyat qilmaydi — faqat ketadi). Sentry buni avtomatik topadi — xato chiqishi bilan sizga xabar (email/Slack), to'liq tafsilot bilan (stack trace, qaysi foydalanuvchi, qanday holatda) — siz darrov tuzatasiz (foydalanuvchilar ketishdan oldin — proaktiv). console.log'lar production'da yetarli emas (siz ko'rmaysiz — server'da yoki brauzer'da yo'qoladi) — Sentry markaziy, qidiriladigan, ogohlantiruvchi. Bu — production monitoring'ning eng muhim qismi (xato — buzilishni topish — 2.8). Sentry'dan tashqari (LogRocket, Bugsnag, Rollbar — o'xshash). Har production ilova xato kuzatuvi bilan (xato yashirin qolmasin — darrov topib tuzatish). Bu — "ko'r" deploy (xato bilmaslik) o'rniga "ko'rib turgan" deploy (xato darrov ma'lum).

Misol 6 — Speed Insights va Analytics (2.8)

Maqsad: Real foydalanuvchi tezligi va tahlilini kuzatish — Vercel Speed Insights va Analytics. Bu Core Web Vitals'ni real foydalanuvchida o'lchaydi 13.7-bob.

tsx

// app/layout.tsx — Speed Insights + Analytics qo'shish
import { SpeedInsights } from "@vercel/speed-insights/next";
import { Analytics } from "@vercel/analytics/react";

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="uz">
      <body>
        {children}

        {/* Real foydalanuvchi tezligi (Core Web Vitals — LCP/CLS/INP — 13.7): */}
        <SpeedInsights />

        {/* Foydalanuvchi tahlili (necha tashrif, qaysi sahifa): */}
        <Analytics />
      </body>
    </html>
  );
}

// Yoki o'z web-vitals (har platformada):
// import { onLCP, onCLS, onINP } from "web-vitals";
// onLCP((metric) => sendToAnalytics(metric));   // tezlikni o'z serveringizga

Bu kod nima qiladi: Bu — real foydalanuvchi tezligi va tahlili (monitoring — 2.8). Ikki komponent (Vercel — root layout'da): (1) <SpeedInsights /> — real foydalanuvchilar qanday tezlikda ko'rayotganini o'lchaydi (Core Web Vitals — LCP, CLS, INP — 13.7: 2.9). Muhim: bu lab test (Lighthouse — sizning kompyuteringizda) emas, balki real foydalanuvchi ma'lumoti (RUM — Real User Monitoring) — har xil qurilma (eski telefon, sekin internet), har xil joy (uzoq mamlakat) — haqiqiy tajriba. Bu sizga "real foydalanuvchilar uchun sayt qancha tez?" javobini beradi (lab'da tez bo'lishi mumkin, lekin real eski telefonda sekin); (2) <Analytics /> — foydalanuvchi tahlili (necha tashrif, qaysi sahifa mashhur, qayerdan keldi — Google, ijtimoiy, to'g'ridan) — biznes qarorlari uchun (qaysi mahsulot ommabop, qaysi sahifa ko'riladi). Yoki web-vitals kutubxonasi (onLCP, onCLS, onINP) — har platformada (Vercel emas) o'z serveringizga tezlik ma'lumotini yuborish (mustaqil). Nega muhim: deploy'dan keyin "sayt tez ishlayaptimi?" savoliga real javob kerak (sizning tez internetingizda tez, lekin foydalanuvchining eski telefonida?). Speed Insights real ma'lumot beradi (qaysi sahifa sekin, qaysi metrika yomon — LCP yoki CLS) — siz aniq optimizatsiya qilasiz (13.7 — taxmin emas, real ma'lumot asosida). Analytics — foydalanuvchi xulqi (biznes). Bu — production monitoring'ning tezlik va foydalanuvchi qismi (Sentry — xato, bu — tezlik/foydalanuvchi). Birga — to'liq rasm (xato + tezlik + foydalanuvchi). Vercel'da bu oson (<SpeedInsights />, <Analytics /> — bir qator), boshqa platformada web-vitals + Google Analytics. Real foydalanuvchi ma'lumoti — optimizatsiyaning yo'naltiruvchisi (nima sekin — o'shani tuzat). Monitoring'siz optimizatsiya — "ko'r" (nima muammo — noaniq).

Misol 7 — Health check va graceful shutdown (2.4, o'z server)

Maqsad: O'z serverda deploy uchun health check endpoint — server sog'ligini tekshirish. Bu load balancer/Kubernetes uchun zarur 10.10-bob.

tsx

// app/api/health/route.ts — health check (server sog'ligi)
import { db } from "@/lib/db";

export async function GET() {
  try {
    // DB ulanishini tekshir (server haqiqatan ishlayaptimi):
    await db.$queryRaw`SELECT 1`;

    return Response.json(
      { status: "healthy", timestamp: new Date().toISOString() },
      { status: 200 }
    );
  } catch (error) {
    // DB yoki boshqa narsa ishlamasa — unhealthy:
    return Response.json(
      { status: "unhealthy", error: "Database connection failed" },
      { status: 503 }   // 503 Service Unavailable
    );
  }
}
//  load balancer/Kubernetes 10.10-bob bu endpointni tekshiradi:
//   200  server sog'lom (trafik yubor)
//   503  server kasal (trafik yuborma, qayta ishga tushir)

Bu kod nima qiladi: Bu — health check endpoint (o'z serverda deploy uchun — 2.4, 10.10). Health check — server "sog'lom" (ishlayapti, ma'lumotga ulana oladi) ekanini tekshiradigan endpoint. app/api/health/route.ts (Route Handler — 13.6): GET — DB ulanishini tekshiradi (db.$queryRaw\SELECT 1`— eng oddiy so'rov — DB javob beradimi), agar muvaffaqiyatli —200 ({ status: "healthy" }), agar DB (yoki boshqa narsa) ishlamasa — 503 Service Unavailable ({ status: "unhealthy" }). **Nega kerak** (ayniqsa o'z server, Kubernetes — 10.10): production'da server bir necha nusxada (replika — yuk taqsimlash) ishlaydi, va **load balancer** (yoki Kubernetes — 10.10) trafikn sog'lom serverlarga yuborishi kerak. Load balancer har serverning /api/healthini muntazam tekshiradi: 200(sog'lom) trafik yuboradi;503` (kasal — masalan DB uzildi, server osildi) trafik yubormaydi (foydalanuvchi kasal serverga tushmaydi) va serverni qayta ishga tushiradi (Kubernetes — avtomatik tiklash — 10.10). Bu — yuqori ishonchlilik (high availability — bir server yiqilsa, foydalanuvchi sezmaydi — boshqa sog'lom serverga yo'naltiriladi). Vercel'da bu avtomatik (Vercel o'zi boshqaradi — serverless), lekin o'z serverda/Kubernetes'da siz health check beratishingiz kerak (load balancer/orkestrator buni ishlatadi). Bu — production'ning ishonchlilik (reliability) qismi — server doimo sog'lom holda (kasal — avtomatik aniqlanadi va tiklanadi). 10-QISM (DevOps — Kubernetes — 10.10)dagi tushunchalar (replika, health, self-healing) bu yerda qo'l keladi. Health check — production-grade deploy'ning standart elementi (o'z infratuzilmada). Oddiy, lekin muhim (server "tirik"mi — avtomatik nazorat).

Misol 8 — Production xato sahifalari (2.10)

Maqsad: Production uchun toza xato va 404 sahifalari — foydalanuvchi oq ekran yoki texnik xato ko'rmasin. Bu professional ilovaning belgisi.

tsx

// app/not-found.tsx — 404 sahifa (sahifa topilmaganda — 13.2)
import Link from "next/link";

export default function NotFound() {
  return (
    <div className="error-page">
      <h1>404</h1>
      <p>Bu sahifa topilmadi.</p>
      <Link href="/">Bosh sahifaga qaytish</Link>   {/* yo'l ko'rsat (boshi berk emas) */}
    </div>
  );
}

// app/error.tsx — xato sahifa (kutilmagan xato — 13.2: 2.5)
"use client";   // error.tsx — har doim Client (13.2)
import { useEffect } from "react";

export default function Error({ error, reset }: { error: Error; reset: () => void }) {
  useEffect(() => {
    // Production'da xatoni log/Sentry'ga (Misol 5):
    console.error(error);   // yoki Sentry.captureException(error)
  }, [error]);

  return (
    <div className="error-page">
      <h2>Nimadir noto'g'ri ketdi</h2>
      <p>Uzr, xatolik yuz berdi. Qayta urinib ko'ring.</p>
      <button onClick={reset}>Qayta urinish</button>   {/* tiklanish imkoni */}
    </div>
  );
}

Bu kod nima qiladi: Bu — production xato sahifalari (foydalanuvchi tajribasini himoya — 2.10). Ikki maxsus fayl (13.2: 2.5 — Next.js konvensiyasi): (1) not-found.tsx (404 — sahifa topilmaganda): foydalanuvchi mavjud bo'lmagan URL'ga kirsa (/mavjud-emas), oddiy server xatosi (texnik "404 Not Found" matni) o'rniga chiroyli, foydali sahifa ("404 — bu sahifa topilmadi" + bosh sahifaga qaytish havolasi — foydalanuvchi boshi berk ko'chada qolmaydi — yo'l ko'rsatiladi); (2) error.tsx (kutilmagan xato — 13.2: 2.5): ilovada xato yuz bersa (masalan API yiqildi, kod xatosi), oq ekran yoki texnik xato (stack trace — foydalanuvchiga qo'pqinchli va xavfsizlik — ichki tafsilot ko'rsatmaslik) o'rniga chiroyli sahifa ("Nimadir noto'g'ri ketdi — qayta urinib ko'ring" + "Qayta urinish" tugmasi — reset — tiklanish imkoni). useEffectda xato log/Sentry'ga (Misol 5 — siz xatoni bilasiz). Nega muhim: production'da xato/404 muqarrar (foydalanuvchi eski havola bosadi, API vaqtincha yiqiladi, kutilmagan holat) — bunda foydalanuvchi oq ekran yoki texnik xato ko'rsa — yomon taassurot (ilova "buzuq", professional emas — ketadi). Toza xato sahifalari — foydalanuvchini ushlab qoladi (xato bo'lsa ham — chiroyli xabar, yo'l ko'rsatish, qayta urinish — tiklanish). Bu — professional ilovaning belgisi (xatoni ham nafis boshqaradi). 404 — yo'l ko'rsat (boshi berk emas), error — tiklanish imkoni (reset) + log (Sentry). Bu sahifalar production'da majburiy (development'da xato to'liq ko'rsatiladi — debug uchun, production'da yashiriladi — foydalanuvchiga toza). Production checklist 2.10-bobning "ishlash" qismi (xatolar boshqaruvi — 404, error). Foydalanuvchi xato ko'rsa ham — yaxshi tajriba (chiroyli, foydali, tiklanadigan). Bu — deploy'ning UX qismi (xato muqarrar — lekin nafis boshqarilgan).

Misol 9 — Build optimizatsiya tekshiruvi (2.1, 2.10)

Maqsad: Deploy'dan oldin build natijasini tekshirish — bundle hajmi, statik/dinamik, xatolar. Bu production checklist'ning performance qismi.

bash

# 1. Build (production — lokalda tekshir):
npm run build

# Natija (Next.js ko'rsatadi — 13.4: Misol 10):
# Route (app)                Size      First Load JS
# ○ /                        1.2 kB    95 kB         statik (yaxshi)
# ○ /about                   0.8 kB    93 kB
# ƒ /dashboard               2.1 kB    110 kB        dinamik
# ● /blog/[slug]             1.5 kB    96 kB         SSG
#
# ○ Static  ● SSG  ƒ Dynamic
# First Load JS — har sahifa boshlang'ich JS (kichik = tez — 13.7)

# 2. Bundle tahlil (katta paketni top — 13.7: Misol 7):
# ANALYZE=true npm run build

# 3. Production'ni lokalda sinash (deploy'dan oldin):
npm run build && npm start
#  localhost:3000'da PRODUCTION versiya (optimizatsiyalangan — real holat)

# 4. Lighthouse (Core Web Vitals — 13.7):
# Chrome DevTools  Lighthouse  Analyze (LCP/CLS/INP tekshir)

Bu kod nima qiladi: Bu — deploy'dan oldin build tekshiruvi (production checklist'ning performance qismi — 2.1, 2.10). To'rt qadam: (1) npm run build — production build (lokalda) — Next.js har route uchun natijani ko'rsatadi (13.4: Misol 10): Size (sahifa kodi), First Load JS (boshlang'ich JavaScript — eng muhim — kichik = tez yuklanish — 13.7), va belgi (○ statik, ● SSG, ƒ dinamik — 13.4). Bu yerda tekshirasiz: sahifalar kutgandek statik/dinamikmi (masalan blog statik bo'lishi kerak — ƒ (dinamik) bo'lsa — nimadir xato — 13.4: Misol 10), First Load JS katta emasmi (110 kB+ — ko'p — optimizatsiya kerak — 13.7); (2) ANALYZE=true npm run build — bundle tahlil (qaysi paket og'ir — 13.7: Misol 7 — katta paketni topib optimizatsiya); (3) npm run build && npm start — production versiyani lokalda sinash (development'dan farqli — optimizatsiyalangan, real holat — deploy'dan oldin "production'da qanday ishlaydi?" — xato bo'lsa bu yerda topiladi, production'da emas); (4) Lighthouse (Chrome DevTools — Core Web Vitals — 13.7: 2.9 — LCP/CLS/INP tekshir). Nega muhim: deploy — production'ga chiqarish (real foydalanuvchi), va u yerda xato/sekinlik qimmat (foydalanuvchi ketadi). Deploy'dan oldin lokalda production build'ni tekshirish (build muvaffaqiyatlimi, bundle kichikmi, sahifalar to'g'ri strategiyada, tezlik yaxshimi) — muammolarni oldindan topadi (production'da emas). Bu — "production'ga chiqarmasdan oldin production'ni sinash" (xavfsiz — surprise yo'q). Production checklist 2.10-bobning performance qismi: build muvaffaqiyatli, bundle tekshir, statik/dinamik to'g'ri, Lighthouse yaxshi. Professional deploy — "build qildi, deploy qildi" emas, balki "build tekshirdi, sinadi, keyin deploy qildi". Bu kichik qadamlar (build natijasini o'qish, Lighthouse) katta muammolarni oldini oladi (sekin sayt, buzuq sahifa production'da). Deploy'dan oldin tekshiruv — sifat kafolati.

Misol 10 — To'liq deploy oqimi (hammasi birga)

Maqsad: Boshidan oxirigacha to'liq deploy oqimini ko'rsatish — kod tayyor tekshir deploy monitoring. Bu butun bobning amaliy yakuni (production hayot sikli).

bash

# === TO'LIQ DEPLOY OQIMI (development  production) ===

# 1. LOKAL TEKSHIRUV (deploy'dan oldin — Misol 9):
npm run lint              # kod sifati
npm run type-check        # TypeScript
npm test                  # testlar (11.17)
npm run build             # build muvaffaqiyatlimi
npm start                 # production'ni lokalda sina

# 2. ENV TEKSHIRUV (Misol 1):
#    - .env.local git'da YO'Q (.gitignore)
#    - production env platformada (Vercel/server) — secret xavfsiz
#    - NEXT_PUBLIC_ faqat public

# 3. GIT + PREVIEW (Misol 4, 2.9):
git checkout -b feature/yangi-xususiyat
git push origin feature/yangi-xususiyat
#     CI ishlaydi (lint+type+test+build — Misol 4)
#     Vercel preview URL (test — 2.9)
#     jamoa ko'radi, tasdiqlaydi

# 4. PRODUCTION (merge  deploy):
#    PR  main merge  Vercel avtomatik production deploy
#    (yoki Docker push  server — Misol 3)

# 5. MONITORING (deploy'dan keyin — Misol 5, 6):
#    - Sentry (xatolar — darrov xabar)
#    - Speed Insights (Core Web Vitals — real foydalanuvchi)
#    - Analytics (foydalanuvchi)
#    - Health check (server sog'ligi — Misol 7)

Bu kod nima qiladi: Bu — to'liq deploy oqimi (boshidan oxirigacha — butun bobning amaliy yakuni — production hayot sikli). Besh bosqich (har biri oldingi misollarni birlashtiradi): (1) lokal tekshiruv (Misol 9) — lint (sifat), type-check (TypeScript), test 11.17-bob, build (muvaffaqiyatlimi), start (production'ni lokalda sinash) — deploy'dan oldin hamma narsa joyidami; (2) env tekshiruv (Misol 1) — .env.local git'da yo'q (secret himoya — 10.11), production env platformada (xavfsiz), NEXT_PUBLIC_ faqat public (secret chiqmasin); (3) git + preview (Misol 4, 2.9) — feature branch'ga push CI ishlaydi (avtomatik lint/type/test/build — buzuq kod o'tmaydi) Vercel preview URL (real muhitda test) jamoa ko'rib tasdiqlaydi; (4) production — PR main'ga merge Vercel avtomatik production deploy (yoki Docker push server — Misol 3); (5) monitoring (deploy'dan keyin — Misol 5, 6) — Sentry (xatolar — darrov), Speed Insights (tezlik — real), Analytics (foydalanuvchi), health check (server sog'ligi — Misol 7). Eng muhim g'oya: deploy — bir martalik "yuklash" emas, balki oqim (sikl): tekshir (lokal) preview (test) production (chiqar) monitoring (kuzat) (xato/yangilanish yana boshidan). Har bosqich xavfsizlikni oshiradi (lokal test preview test CI test monitoring — bir necha qatlam — xato production'ga yetib bormaydi, yetsa ham darrov topiladi). Eng keng xato — bosqichlarni o'tkazib yuborish (to'g'ridan production'ga push, test'siz, monitoring'siz — "ko'r" deploy — xato chiqsa bilmaysiz, foydalanuvchi ketadi). To'g'ri: har bosqich (tekshir preview CI production monitoring). Bu — professional deploy madaniyati (10-QISM DevOps + 13-QISM Next.js — birga). Deploy — kod yozishning yakuniy maqsadi (ishlaydigan, ko'rinadigan, kuzatiladigan mahsulot), va u mas'uliyat bilan qilinadi (real foydalanuvchilar — sifat, xavfsizlik, ishonchlilik). Bu oqim — har Next.js loyihasini professional, ishonchli tarzda dunyoga chiqarish yo'li. 13-QISM (Next.js)ning amaliy cho'qqisi: g'oyadan 13.1-bob to real, monitoring qilinadigan production'gacha 13.10-bob.

5. To'g'ri va noto'g'ri holatlar

1) Secret env

text

 NEXT_PUBLIC_STRIPE_SECRET (secret brauzerga — falokat — 2.3)
 STRIPE_SECRET_KEY (server-only — Misol 1)

2) .env git'da

text

 .env commit qilingan (secret git tarixida — 10.11)
 .gitignore'da; production env platformada (Misol 1)

3) Deploy oldidan

text

 to'g'ridan production'ga push (test'siz)
 lokal tekshir + preview + CI (Misol 9, 10)

4) Monitoring

text

 deploy qildi, unutdi ("ko'r" — xato bilmaydi)
 Sentry + Speed Insights (kuzat — Misol 5, 6)

5) Xato sahifalari

text

 production'da oq ekran/texnik xato (yomon UX — 2.10)
 not-found.tsx + error.tsx (toza — Misol 8)

6) Image domenlari

text

 next.config'da remotePatterns yo'q (tashqi rasm ishlamaydi)
 remotePatterns (ruxsat etilgan domen — Misol 2)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Build production'da yiqildi (lokalda ishlardi)

Sababi: env yo'q (production'da) yoki TypeScript xatosi (dev'da e'tiborsiz). Yechimi: production env to'liq; npm run build lokalda tekshir (Misol 9).

Xato 2 — Secret brauzerda ko'rindi

Sababi: NEXT_PUBLIC_ bilan secret 2.3-bob. Yechimi: secret NEXT_PUBLIC_siz (server-only — Misol 1).

Xato 3 — Tashqi rasm ishlamaydi (next/image)

Sababi: remotePatterns yo'q 2.5-bob. Yechimi: next.config'da domen qo'sh (Misol 2).

Xato 4 — "Module not found" production'da

Sababi: katta-kichik harf (Linux server — case-sensitive; Windows emas). Yechimi: import yo'llarini aniq (Button vs button).

Xato 5 — Docker image juda katta

Sababi: standalone yo'q yoki multi-stage emas 2.5-bob. Yechimi: output: "standalone" + multi-stage (Misol 3).

Xato 6 — Production'da xato bilinmaydi

Sababi: monitoring yo'q 2.8-bob. Yechimi: Sentry + logging (Misol 5).

Xato 7 — Environment variable undefined (production)

Sababi: platformada env qo'shilmagan (faqat .env.local — dev). Yechimi: Vercel/server sozlamasida env qo'sh.

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

DevOps (10-QISM): Docker 10.6-bob, CI/CD 10.9-bob, server 10.4-bob, Nginx/SSL (10.7, 10.8), K8s 10.10-bob.
Performance 13.7-bob: build optimizatsiya, bundle, Core Web Vitals (Speed Insights).
SEO 13.8-bob: production HTTPS, domen — SEO omillari.
Auth 13.9-bob: AUTH_SECRET, env (production secret).
Rendering 13.4-bob: build natija (statik/dinamik); standalone.
Route Handlers 13.6-bob: health check endpoint.
Xavfsizlik (14): secret, HTTPS, header (production).
Error boundaries 13.2-bob: error.tsx, not-found.tsx (production xato).

8. Eng yaxshi amaliyotlar (best practices)

Secret server-only (NEXT_PUBLIC_ faqat public — 2.3, Misol 1).
.env git'da yo'q (.gitignore; production platformada — 10.11).
Vercel (oson) yoki Docker (nazorat) (2.4, Misol 3).
CI/CD (avtomatik test+build) (buzuq kod o'tmasin — 2.6, Misol 4).
Preview'da test (production'dan oldin — 2.9).
Monitoring (Sentry + Speed Insights) (deploy'dan keyin kuzat — 2.8).
Production xato sahifalari (not-found/error — 2.10, Misol 8).
Build lokalda tekshir (deploy'dan oldin — Misol 9).
Health check (o'z server/K8s — Misol 7).
Production checklist (xavfsizlik+performance+SEO+monitoring — 2.10).

9. Amaliy loyiha: "To'liq Deploy (Production'ga chiqarish)"

Next.js ilovani real production'ga chiqarishni mustahkamlash.

Maqsad

Tayyor Next.js ilovani (oldingi boblar) production'ga deploy: Vercel yoki Docker, env, monitoring, checklist.

Talablar (requirements)

Env: secret server-only, public NEXT_PUBLIC_ (Misol 1).
next.config: standalone, image domenlari, header (Misol 2).
Deploy: Vercel (git) yoki Docker (Misol 3).
CI/CD: lint+type+test+build (Misol 4).
Preview: branch preview test 2.9-bob.
Domen + HTTPS: o'z domen, SSL 2.7-bob.
Monitoring: Sentry + Speed Insights (Misol 5, 6).
Xato sahifalari: not-found + error (Misol 8).
Build tekshir: lokalda production sina (Misol 9).
Checklist: to'liq production checklist 2.10-bob.

Maslahatlar (hint)

Secret NEXT_PUBLIC_siz (Xato 2).
.env git'da yo'q (.gitignore).
Image domenlari (Xato 3).
CI/CD (buzuq kod o'tmasin — Misol 4).
Monitoring (deploy'dan keyin — Xato 6).
Build lokalda tekshir (Xato 1).

"Tayyor" mezonlari (acceptance criteria)

Env to'g'ri (secret/public).
Deploy (Vercel yoki Docker).
CI/CD (avtomatik tekshir).
Preview (test).
Domen + HTTPS.
Monitoring (xato + tezlik).
Xato sahifalari (toza).
Production checklist o'tdi.

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda Next.js'ni production'ga deploy qilishni chuqur o'rgandik:

Deploy asoslari/build 2.1-bob; Vercel 2.2-bob; environment variables 2.3-bob; boshqa platformalar (Docker — 2.4); standalone 2.5-bob.
CI/CD 2.6-bob; domen/HTTPS 2.7-bob; monitoring (Sentry/Analytics — 2.8); preview 2.9-bob; production checklist 2.10-bob.

Endi siz Next.js ilovani real dunyoga chiqara olasiz: Vercel (oson) yoki Docker (nazorat), xavfsiz env, CI/CD, monitoring, va to'liq checklist bilan. Bu — butun mehnatingizning maqsadi (ishlaydigan, ko'rinadigan, kuzatiladigan mahsulot).

Keyingi bob — 13.11-bob: Next.js — Yakuniy loyiha va amaliyot. 13-QISMni yakunlaymiz: o'rgangan barcha narsani (App Router, Server Components, rendering, Server Actions, auth, SEO, deploy) bitta to'liq, real loyihada birlashtiramiz — to'liq full-stack Next.js ilova (masalan e-commerce yoki blog platformasi) — g'oyadan deploy'gacha. Bu — 13-QISMning amaliy cho'qqisi va sizning portfelingiz uchun loyiha.

Foydalanilgan rasmiy/ishonchli manbalar

Next.js rasmiy hujjati — "Deploying", "Production Checklist", "Self-Hosting", "Static Exports", "Runtimes (Edge/Node)", "Caching and Revalidating (ISR)", "Configuring: Headers"
Vercel hujjati — deploy, environment variables, preview deployments, Edge Network, Analytics, Speed Insights, rollback (Instant Rollback)
Docker hujjati — Next.js standalone output va multi-stage build; GitHub Actions hujjati — CI/CD workflow (10.9 bilan)
Boshqa platformalar rasmiy hujjatlari — Netlify, Railway, Render, AWS Amplify, Cloudflare Pages (Next.js deploy qo'llanmalari)
PM2 hujjati — process manager (doimiy ishlash, startup); Nginx hujjati — reverse proxy va kesh header (10.7)
Prisma hujjati — migrate deploy (production migratsiya); sharp — self-host image optimizatsiya
Sentry hujjati — Next.js error tracking; web.dev — Core Web Vitals (LCP/CLS/INP)
OWASP Secure Headers loyihasi va MDN — HTTP xavfsizlik header'lari (CSP, HSTS, X-Frame-Options)

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!