GitHub Codespaces ile Tarayıcı Üzerinden Bulut Geliştirme Ortamı Kurma

Yazar:komut.io ekibi GitHub Kullanımı ve Workflow
0 Yorum

Laptop yanıyor, fan çıldırmış durumda, yerel ortamınız bir türlü düzgün çalışmıyor ve deadline yaklaşıyor. Ya da tam tersine, hafif bir Chromebook ile kafede oturuyorsunuz ve ciddi bir geliştirme ortamına ihtiyacınız var. İşte GitHub Codespaces tam da bu noktada hayat kurtarıyor. Tarayıcı üzerinden, herhangi bir cihazdan, tam teşekküllü bir VS Code ortamıyla geliştirme yapabiliyorsunuz. Bu yazıda Codespaces’i sıfırdan kurmayı, yapılandırmayı ve gerçek dünya senaryolarında verimli kullanmayı ele alacağız.

GitHub Codespaces Nedir ve Neden Önemlidir

GitHub Codespaces, bulut üzerinde çalışan geliştirme ortamlarıdır. Her codespace, bir Docker container içinde çalışır ve size tam bir Linux ortamı sunar. VS Code’un tarayıcı versiyonu arayüz olarak kullanılır, ya da issterseniz yerel VS Code’unuzu uzak makineye bağlayabilirsiniz.

Bir sysadmin veya DevOps mühendisi olarak şunu düşünebilirsiniz: “Benim zaten güçlü bir local ortamım var, neden buluta taşıyayım ki?” Birkaç somut senaryo üzerinden düşünelim.

Ekibinize yeni bir developer geldi. Yerel ortam kurulumu için geçmişte ortalama 2-3 gün harcıyordunuz. Node versiyonu çakışıyor, Python virtual environment karışıyor, Docker daemon davranıyor. Codespaces ile bu süreç 30 saniyeye düşüyor. Repo’yu açıyorsunuz, codespace başlatıyorsunuz ve her şey hazır.

Ya da şirketinizde güvenlik politikaları gereği kaynak kodun yerel makinelere indirilmesi yasak. Codespaces tam olarak bunu çözüyor; kod hiçbir zaman developer’ın bilgisayarına inmiyor, hep bulutta kalıyor.

Codespaces’i Aktive Etme ve İlk Ortamı Başlatma

Codespaces’i kullanmak için GitHub hesabınızın bunu desteklemesi gerekiyor. GitHub Free planında ayda 60 saat 2-core makine kullanımı ücretsiz geliyor. Pro ve Team planlarında bu limit daha yüksek.

Herhangi bir repo üzerinde Codespace başlatmak için:

  1. Repo sayfasında yeşil Code butonuna tıklayın
  2. Codespaces sekmesine geçin
  3. Create codespace on main deyin

Bu kadar. Birkaç dakika içinde karşınızda tam bir VS Code ortamı olacak. Ama asıl güç, bu ortamı özelleştirmekte yatıyor.

devcontainer.json ile Ortam Yapılandırması

Codespaces’in kalbi devcontainer.json dosyasıdır. Bu dosya, geliştirme ortamınızın nasıl görüneceğini tanımlar. Repo’nuzun .devcontainer/ dizinine koyarsınız ve Codespaces her başladığında bu konfigürasyonu kullanır.

Temel bir Node.js projesi için örnek:

mkdir -p .devcontainer
cat > .devcontainer/devcontainer.json << 'EOF'
{
  "name": "Node.js Geliştirme Ortamı",
  "image": "mcr.microsoft.com/devcontainers/node:20",
  "features": {
    "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers/features/github-cli:1": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode",
        "ms-vscode.vscode-typescript-next"
      ],
      "settings": {
        "editor.formatOnSave": true,
        "editor.defaultFormatter": "esbenp.prettier-vscode"
      }
    }
  },
  "postCreateCommand": "npm install",
  "forwardPorts": [3000, 5432],
  "portsAttributes": {
    "3000": {
      "label": "Uygulama",
      "onAutoForward": "openPreview"
    }
  }
}
EOF

Buradaki kritik alanları açıklayalım:

  • image: Hangi Docker imajını temel alacağınız. Microsoft’un hazır devcontainer imajları production-ready olarak geliyor.
  • features: Ek araçlar eklemek için kullanılan modüler yapı. Git, GitHub CLI, Docker gibi onlarca hazır feature var.
  • postCreateCommand: Container ayağa kalktıktan sonra çalışacak komut. npm install, pip install -r requirements.txt gibi setup komutlarını buraya yazarsınız.
  • forwardPorts: Container içindeki portları dışarıya açmak için. 3000 portunu açtığınızda uygulamanıza tarayıcıdan erişebiliyorsunuz.

Python ve PostgreSQL’li Gerçek Dünya Senaryosu

Diyelim ki bir Django projesi geliştiriyorsunuz ve veritabanı olarak PostgreSQL kullanıyorsunuz. Bunu yerel ortamda kurmak başlı başına bir macera. Codespaces ile her şeyi tek dosyada tanımlayabilirsiniz.

{
  "name": "Django + PostgreSQL",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app",
  "workspaceFolder": "/workspace",
  "features": {
    "ghcr.io/devcontainers/features/python:1": {
      "version": "3.11"
    }
  },
  "postCreateCommand": "pip install -r requirements.txt && python manage.py migrate",
  "forwardPorts": [8000, 5432],
  "remoteEnv": {
    "DATABASE_URL": "postgresql://postgres:postgres@db:5432/myapp"
  }
}

Yanına bir de docker-compose.yml ekliyoruz:

version: '3.8'
services:
  app:
    build:
      context: .
      dockerfile: .devcontainer/Dockerfile
    volumes:
      - ../..:/workspace:cached
    command: sleep infinity
    environment:
      - DATABASE_URL=postgresql://postgres:postgres@db:5432/myapp
    depends_on:
      - db

  db:
    image: postgres:15
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

Bu yapıda Codespace başladığında hem Django uygulamanız hem de PostgreSQL veritabanınız ayağa kalkıyor. python manage.py runserver dediğinizde uygulama çalışıyor, port forwarding sayesinde tarayıcıdan localhost:8000 ile erişebiliyorsunuz.

GitHub CLI ile Codespaces Yönetimi

Terminal aşığı bir sysadmin olarak muhtemelen GUI yerine CLI’dan yönetmek isteyeceksiniz. GitHub CLI bu konuda tam anlamıyla güçlü bir araç sunuyor.

Önce GitHub CLI’yı authenticate edin:

gh auth login

Tüm codespace’lerinizi listeleyin:

gh codespace list

Belirli bir repo için codespace oluşturun:

gh codespace create 
  --repo kullanici/repo-adi 
  --branch feature/yeni-ozellik 
  --machine standardLinux32gb

Mevcut bir codespace’e SSH ile bağlanın:

gh codespace ssh --codespace CODESPACE_ADI

Bu son özellik çok işe yarıyor. Codespace’inizi SSH üzerinden yönetebiliyorsunuz, sanki bir remote sunucuya bağlanır gibi. Tmux, Vim, htop, her şeyi kullanabiliyorsunuz.

Kullanılmayan codespace’leri kapatın (para birikiyor!):

gh codespace stop --codespace CODESPACE_ADI

Secrets ve Environment Variable Yönetimi

Üretim ortamına benzer konfigürasyon için API anahtarları ve secrets’ları güvenli şekilde yönetmek kritik önem taşıyor. Codespaces’te bunu GitHub’ın kendi secrets mekanizmasıyla yapıyorsunuz.

GitHub ayarlarından Settings > Codespaces > Secrets yolunu izleyerek secret ekleyebilirsiniz. Ya da CLI üzerinden:

gh secret set MY_API_KEY --app codespaces

Bu secret’lar codespace içinde environment variable olarak otomatik görünür hale geliyor. devcontainer.json içinde bu değerlere referans verebilirsiniz:

{
  "remoteEnv": {
    "AWS_ACCESS_KEY_ID": "${localEnv:AWS_ACCESS_KEY_ID}",
    "STRIPE_SECRET_KEY": "${localEnv:STRIPE_SECRET_KEY}"
  }
}

Böylece API anahtarlarınız ne koda giriyor ne de başkalarının görebileceği bir yerde duruyor.

Prebuilds ile Hız Optimizasyonu

Codespace başlatmak bazen yavaş olabilir, özellikle postCreateCommand içinde ağır dependency kurulumları varsa. Prebuilds bu sorunu çözüyor.

Prebuilds, devcontainer.json konfigürasyonunuzu önceden build edip hazır tutuyor. Siz codespace başlattığınızda sıfırdan build etmek yerine hazır snapshot’ı kullanıyor.

Prebuild’i aktive etmek için:

  1. Repo’nuzda Settings > Codespaces gidin
  2. Set up prebuild seçin
  3. Branch, region ve tetikleyici seçin

Genellikle her push’ta ya da belirli aralıklarla prebuild tetiklenir. Production ortamında büyük bir ekiple çalışıyorsanız bu özelliği mutlaka kullanın. 5 dakikalık codespace başlama süresi 30 saniyeye düşüyor.

Prebuild konfigürasyonunu .github/workflows/prebuild.yml ile de yönetebilirsiniz:

name: Codespace Prebuild
on:
  push:
    branches:
      - main
      - develop
  schedule:
    - cron: '0 6 * * 1-5'

jobs:
  prebuild:
    runs-on: ubuntu-latest
    steps:
      - name: Prebuild tetikle
        uses: github/codespaces-prebuild-action@v1
        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

Dotfiles ile Kişisel Ortam Taşıma

Her sysadmin’in kendine özel terminal konfigürasyonu, alias’ları ve araçları vardır. Codespaces başladığında bunların hepsini sıfırdan kurmak can sıkıcı olur. Dotfiles özelliği bu sorunu çözüyor.

GitHub hesabınızda dotfiles adında bir public repo oluşturun. İçine kişisel konfigürasyonlarınızı koyun:

# dotfiles/install.sh
#!/bin/bash

# Zsh ve Oh My Zsh kurulumu
sudo apt-get install -y zsh
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" "" --unattended

# Alias'lar
cat >> ~/.zshrc << 'ALIASES'
alias ll='ls -alh'
alias gs='git status'
alias gp='git push'
alias gpl='git pull'
alias dc='docker compose'
alias k='kubectl'
ALIASES

# Vim konfigürasyonu
cp .vimrc ~/.vimrc

# Tmux konfigürasyonu
cp .tmux.conf ~/.tmux.conf

echo "Dotfiles kurulumu tamamlandı!"

GitHub Settings > Codespaces sayfasından dotfiles repo’nuzu seçin. Artık her yeni codespace başladığında bu script otomatik çalışıyor ve kişisel ortamınız hazır geliyor.

Codespace Performance Tuning

Varsayılan 2-core machine bazen yetmez. Özellikle büyük TypeScript projeleri veya ağır build süreçlerinde daha güçlü makine tipine geçmek gerekebilir.

Mevcut bir codespace’in makine tipini değiştirmek için:

gh codespace edit 
  --codespace CODESPACE_ADI 
  --machine premiumLinux

Kullanılabilir makine tipleri:

  • basicLinux32gb: 2 core, 8 GB RAM, 32 GB disk
  • standardLinux32gb: 4 core, 16 GB RAM, 32 GB disk
  • premiumLinux: 8 core, 32 GB RAM, 64 GB disk
  • largePremiumLinux: 16 core, 64 GB RAM, 128 GB disk

devcontainer.json içinde de makine tipini zorlayabilirsiniz:

{
  "hostRequirements": {
    "cpus": 4,
    "memory": "16gb",
    "storage": "32gb"
  }
}

Bu sayede proje gereksinimlerine göre minimum donanım belirtebiliyorsunuz. Eğer bir developer 2-core ile codespace açmaya çalışırsa uyarı alıyor.

Port Forwarding ve Uygulama Paylaşımı

Codespace içinde çalışan bir uygulamayı başkasıyla paylaşmak bazen çok işe yarıyor. Bir bug’ı müşteriye göstermek, QA ekibinin test yapması için mükemmel.

# VS Code terminal içinde port'u public yap
gh codespace ports visibility 3000:public --codespace CODESPACE_ADI

Ya da VS Code’da Ports panelinden port’a sağ tıklayıp Port Visibility > Public seçin.

Public port URL’si şu formatta geliyor: https://CODESPACE_ADI-3000.app.github.dev

Bu URL’yi paylaştığınızda GitHub hesabına giriş yapmış herkes uygulamanıza erişebiliyor. Güvenli bir şekilde temporary demo ortamı oluşturdunuz.

Dikkat: İşiniz bittiğinde port’u tekrar private’a çekin ya da codespace’i durdurun. Public port’u unutup açık bırakmak güvenlik riski oluşturabilir.

Codespaces Maliyetini Kontrol Altına Alma

Kurumsal ortamda Codespaces kullanıyorsanız maliyet yönetimi kritik. Birkaç pratik öneri:

İnactivity timeout ayarı: Kullanılmayan codespace’lerin otomatik durması için süre belirleyin. Settings > Codespaces > Default idle timeout altından 30 dakika ile 4 saat arasında ayarlayın.

Retention policy: Durdurulmuş codespace’lerin kaç gün sonra silineceğini belirleyin. Varsayılan 30 gün ama bunu kısaltmak maliyeti düşürür.

Organizasyon politikaları: Org admin olarak kullanılabilir makine tiplerini kısıtlayabilirsiniz. Herkes 16-core makine açmasın diye:

gh api 
  --method PUT 
  -H "Accept: application/vnd.github+json" 
  /orgs/ORG_ADI/codespaces/policy 
  -f allowed_values='["standardLinux32gb"]'

Codespace kullanım raporunu izleyin:

gh api /orgs/ORG_ADI/settings/billing/codespaces

Gerçek Dünya: Acil Hotfix Senaryosu

Saat 23:00, production’da kritik bir bug var. Laptop’ınız evinizde, siz başka bir şehirdesiniz, yanınızda sadece tablet var. Eski dünyada bu ciddi bir problem. Codespaces dünyasında:

Telefondan ya da tabletten tarayıcıyı açın, GitHub’a gidin, ilgili repo’ya gelin. Etkilenen branch üzerinde codespace başlatın. Birkaç dakika içinde tam geliştirme ortamınız hazır. Bug’ı bulun, düzeltin, test edin, PR açın. Nöbetçi arkadaşınız merge yapsın, deploy gitsin.

Bu senaryo artık teorik değil, birçok ekip bunu aktif olarak kullanıyor.

Codespaces vs Alternatifler

Codespaces tek seçenek değil elbette. Gitpod, Google Cloud Shell Editor, AWS Cloud9 benzer çözümler sunuyor. Ama GitHub ekosistemiyle bu kadar derin entegrasyonu başka araçta bulmak zor. PR’ları codespace içinden review etmek, issue’larla doğrudan bağlantı kurmak, Actions ile entegrasyon… Bunların hepsi GitHub workflow’unuzu güçlendiriyor.

Yerel geliştirmeye tamamen alternatif değil, tamamlayıcı bir araç olarak düşünmek daha doğru. Güçlü bir local ortamınız varsa bunu bırakmanıza gerek yok. Ama Codespaces’i toolbelt’inizin bir parçası haline getirdiğinizde ne kadar işe yaradığını göreceksiniz.

Sonuç

GitHub Codespaces, modern geliştirme workflow’unda artık görmezden gelemeyeceğimiz bir araç haline geldi. “Benim makinemde çalışıyor” problemini kökten çözüyor, onboarding süreçlerini dramatik biçimde kısaltıyor ve geliştirme ortamını kod olarak yönetmenizi sağlıyor.

devcontainer.json ile ortamı standartlaştırmak, prebuildler ile hızlandırmak, dotfiles ile kişiselleştirmek ve GitHub CLI ile yönetmek bunların hepsi birbirine entegre çalışıyor. Küçük bir projede denemek için maliyetiniz yok, ücretsiz tier oldukça cömert.

Başlangıç noktanız şu olsun: Mevcut bir projenize .devcontainer/devcontainer.json ekleyin, bir codespace başlatın ve bir hafta boyunca günlük işlerinizin bir kısmını buradan yapın. O hafta sonunda bu aracın yerini daha iyi anlayacaksınız. Altyapıyı kod olarak yönettiğiniz gibi artık geliştirme ortamını da kod olarak yönetme zamanı geldi.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir