GitHub Copilot ile Yapay Zeka Destekli Kod Yazımı

Yazar:komut.io ekibi
0 Yorum

Bir süredir ekibimde Copilot kullanıyoruz ve açıkçası ilk başta “bu da ne kadar işe yarayacak” diye düşünmüştüm. Bir hafta sonra shell scriptlerimi neredeyse yarı sürede yazmaya başlayınca fikrim değişti. Ama bu araç hakkında net olmak lazım: Copilot sihirli bir kutu değil, deneyimli bir junior developer gibi düşünmek daha doğru. Her önerisini körü körüne kabul etmek yerine, sizi hızlandıran ama denetim gerektiren bir yardımcı.

GitHub Copilot Nedir ve Sistem Yöneticisi İçin Ne İfade Eder

GitHub Copilot, OpenAI’nin Codex modeli üzerine inşa edilmiş, GitHub tarafından sunulan yapay zeka destekli bir kod tamamlama aracıdır. VS Code, Neovim, JetBrains IDE’leri ve hatta terminalde bile kullanılabiliyor. Aylık yaklaşık 10 dolar bireysel, 19 dolar iş planıyla geliyor. GitHub Enterprise hesabı olanlar için kurumsal lisans seçenekleri mevcut.

Sysadmin perspektifinden bakıldığında Copilot’un en çok parladığı yerler şunlar: Bash/Python scriptleri, Ansible playbook’ları, Dockerfile ve docker-compose dosyaları, Kubernetes manifest’leri ve GitHub Actions workflow’ları. Yani tam olarak bizim günlük hayatımızın içinde olan şeyler.

Kurulum ve İlk Yapılandırma

VS Code üzerinde kurulum son derece basit. Extension marketplace’ten “GitHub Copilot” aramanız yeterli.

# VS Code CLI üzerinden kurulum
code --install-extension GitHub.copilot
code --install-extension GitHub.copilot-chat

Neovim kullanıyorsanız, ki ekibimizin yarısı Neovim’de çalışıyor, resmi Copilot.vim eklentisi var:

# Neovim için lazy.nvim ile kurulum
# ~/.config/nvim/lua/plugins/copilot.lua dosyasına ekleyin
# {
#   "github/copilot.vim",
#   event = "InsertEnter",
# }

# Kurulum sonrası authentication
:Copilot setup
# Açılan tarayıcıda GitHub hesabınızla giriş yapın

Kurulum sonrasında birkaç ayarı düzenlemek işleri kolaylaştırıyor. VS Code settings.json’a şunu ekleyebilirsiniz:

{
  "github.copilot.enable": {
    "*": true,
    "yaml": true,
    "markdown": false,
    "plaintext": false
  },
  "github.copilot.inlineSuggest.enable": true
}

Markdown ve plaintext’i kapattım çünkü belge yazarken sürekli öneri gelmesi odağı bozuyor. Tercihe göre değişir tabii.

Copilot’u Etkili Kullanmanın Temeli: Yorum Odaklı Geliştirme

Copilot’tan en iyi verimi almak için zihinsel modeli değiştirmeniz gerekiyor. Kodu yazmaya başlayıp Copilot’un tamamlamasını beklemek yerine, ne yapmak istediğinizi yorum olarak yazın. Bu yaklaşım önerinin kalitesini dramatik biçimde artırıyor.

Örnek vermek gerekirse, bir log rotation scripti yazmaya çalıştığınızda şunu deneyin:

#!/bin/bash
# Script: log_rotation.sh
# Amaç: /var/log/app altındaki logları 30 günden eskiyse sil,
# 7 günden eskiyse gzip ile sıkıştır, işlemleri audit.log'a kaydet

# Copilot buradan devam ediyor ve gerçekten işe yarar bir şey üretiyor

Bu yaklaşımla Copilot’un ürettiği şey şuna benziyor olacak:

#!/bin/bash

LOG_DIR="/var/log/app"
AUDIT_LOG="/var/log/audit.log"
COMPRESS_DAYS=7
DELETE_DAYS=30

log_message() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$AUDIT_LOG"
}

# 30 günden eski logları sil
find "$LOG_DIR" -name "*.log" -mtime +"$DELETE_DAYS" -type f | while read -r file; do
    log_message "SİLİNDİ: $file"
    rm -f "$file"
done

# 7 günden eski ama 30 günden genç logları sıkıştır
find "$LOG_DIR" -name "*.log" -mtime +"$COMPRESS_DAYS" -mtime -"$DELETE_DAYS" -type f | while read -r file; do
    log_message "SIKIŞTIRILDI: $file"
    gzip "$file"
done

log_message "Log rotation tamamlandı"

Hiç kod yazmadan, sadece yorum satırları ile makul bir script çıktı ortaya. Elbette production’a almadan önce test edin, ama başlangıç noktası olarak mükemmel.

Ansible Playbook Yazımında Copilot Kullanımı

Ansible playbook’larında Copilot gerçekten güçlü. Özellikle task isimleri çok belirleyici. İyi bir task ismi yazarsanız, altındaki YAML’ı neredeyse hatasız tamamlıyor.

---
- name: Web sunucusu kurulum ve sertleştirme playbook'u
  hosts: webservers
  become: yes
  vars:
    nginx_worker_processes: auto
    allowed_ssh_ips:
      - 10.0.0.0/8
      - 192.168.1.0/24

  tasks:
    - name: Sistem paketlerini güncelle ve nginx kur
      # Copilot buradan apt modülü ile devam ediyor

Gördüğüm kadarıyla Copilot, vars bloğunda tanımladığınız değişkenleri okuyup task’larda kullanıyor. allowed_ssh_ips değişkenini tanımlarsanız, firewall task’ında bunu ufw loop’una dahil ediyor. Bu bağlam okuma yeteneği gerçekten etkileyici.

GitHub Actions Workflow’larında Pratik Kullanım

CI/CD pipeline yazarken Copilot’tan en çok verim aldığım alan burası. Workflow syntax’ı karmaşık ve dokümantasyon okumak zaman alıyor. Copilot bu yükü önemli ölçüde azaltıyor.

name: Docker Build ve Registry Push

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

# Copilot'a ne istediğimizi yorumla anlatalım:
# - Multi-stage build kullan
# - GitHub Container Registry'e push et
# - Cache layer kullan build süresini kısalt
# - Sadece main branch'te production tag oluştur
# - Security scan için trivy çalıştır

jobs:
  build-and-push:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

Bu noktadan sonra Copilot’un ürettiği workflow genellikle şöyle bir şey oluyor:

    steps:
      - name: Kodu checkout et
        uses: actions/checkout@v4

      - name: Docker Buildx kur
        uses: docker/setup-buildx-action@v3

      - name: GitHub Container Registry'e giriş yap
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Docker meta bilgilerini hazırla
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: ghcr.io/${{ github.repository }}
          tags: |
            type=ref,event=branch
            type=sha,prefix={{branch}}-
            type=raw,value=latest,enable={{is_default_branch}}

      - name: Build et ve push yap
        uses: docker/build-push-action@v5
        with:
          context: .
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - name: Trivy güvenlik taraması yap
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ghcr.io/${{ github.repository }}:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH

Bu workflow’u elle yazmak 20-30 dakika alırdı. Copilot ile 5 dakikada aldım ve sadece ince ayarlar yaptım. Trivy entegrasyonunu hatta ben istemedim, bağlamdan anlayıp ekledi.

Copilot Chat: Terminoloji ve Komut Araştırması

VS Code’daki Copilot Chat özelliği ayrı bir güç. Özellikle “bu komutun ne yaptığını açıkla” veya “şu hatanın sebebi ne olabilir” gibi sorularda çok işlevsel.

Ekipteki bir arkadaşım geçen hafta şöyle bir senaryo yaşadı: Kubernetes pod’ları sürekli OOMKilled oluyordu. Copilot Chat’e şu komutu yapıştırdı:

# Kullanıcının terminale yapıştırdığı komut
kubectl get events --all-namespaces --field-selector reason=OOMKilling 
  --sort-by='.metadata.creationTimestamp' | tail -20

Chat’e sordu: “Bu komutun çıktısından OOMKill pattern’i nasıl analiz ederim?” Copilot sadece komutu açıklamakla kalmayıp, limits/requests ayarlarının nasıl optimize edileceğini ve VPA (Vertical Pod Autoscaler) kurulumuna kadar yol gösterdi. Stack Overflow’da 4-5 farklı thread okuyacak yerde tek konuşmada halledildi.

Terraform ile Infrastructure as Code Yazımı

Copilot, Terraform resource bloklarını yazmada da oldukça yetenekli. Özellikle provider spesifik syntax’ı hatırlamak zorunda kalmıyorsunuz.

# AWS üzerinde VPC, public/private subnet, NAT gateway
# ve bastion host içeren temel ağ altyapısı
# Multi-AZ yapıda, tag'ler merkezi yönetimle

locals {
  common_tags = {
    Environment = var.environment
    Project     = var.project_name
    ManagedBy   = "terraform"
  }
}

# Copilot buradan VPC resource'unu, CIDR bloklarını,
# subnet'leri ve NAT gateway'i otomatik tamamlıyor

Bir not: Copilot bazen eski Terraform syntax’ı öneriyor. Özellikle 0.12 öncesi syntax’ı zaman zaman karıştırıyor. Versiyon belirtmek bunu düzeltiyor:

# Terraform >= 1.5, AWS Provider >= 5.0 kullanılıyor
terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

Bu bloku dosyanın başına koyduğunuzda Copilot güncel syntax’a uygun öneriler vermeye başlıyor.

Güvenlik Açısından Dikkat Edilmesi Gerekenler

Burada açık konuşmak lazım. Copilot her önerisini kabul ettirmeye çalışan bir satış elemanı gibi davranıyor. Sysadmin olarak şu noktalarda çok dikkatli olun:

Hardcoded credentials riski: Copilot bazen örnek kodlarda placeholder yerine gerçek gibi görünen değerler öneriyor. Özellikle şunları asla kabul etmeyin:

# YANLIŞ - Copilot bazen böyle önerebilir
export AWS_SECRET_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# DOĞRU - Her zaman environment variable veya secret manager kullanın
export AWS_SECRET_KEY="${AWS_SECRET_KEY}"
# veya
aws configure --profile myprofile

Güvensiz default’lar: Copilot güvenlik best practice’lerini her zaman uygulamıyor. Örneğin firewall kurallarında 0.0.0.0/0 önerebiliyor, ya da chmod 777 ile hızlı çözüm sunabiliyor.

Eski kütüphane versiyonları: Python scriptlerinde bazen güvenlik açığı bulunan eski library versiyonlarını öneriyor. requirements.txt’i her zaman gözden geçirin.

Ekibimizde şöyle bir kural koyduk: Copilot önerisini direkt commit etmek yasak. Kod review sürecine dahil etmek zorunlu. Bu basit kural ciddi sorunların önüne geçti.

Copilot ile Test Yazımı: Sysadmin’in Atladığı Konu

Sysadminlerin çoğu scriptleri için test yazmıyor. Copilot bu konuda gerçekten yardımcı oluyor çünkü “bunu test et” demek yeterli.

#!/usr/bin/env bats
# log_rotation.sh için BATS test dosyası
# Copilot'a: "log_rotation.sh scriptinin BATS testlerini yaz" dedik

setup() {
    TEST_DIR=$(mktemp -d)
    LOG_DIR="$TEST_DIR/logs"
    mkdir -p "$LOG_DIR"
}

teardown() {
    rm -rf "$TEST_DIR"
}

@test "30 günden eski log dosyaları silinmeli" {
    # 31 gün önce oluşturulmuş dosya simüle et
    touch -d "31 days ago" "$LOG_DIR/old_app.log"
    
    LOG_DIR="$LOG_DIR" bash log_rotation.sh
    
    [ ! -f "$LOG_DIR/old_app.log" ]
}

@test "7 günden genç log dosyaları dokunulmamalı" {
    touch -d "3 days ago" "$LOG_DIR/recent_app.log"
    echo "test content" > "$LOG_DIR/recent_app.log"
    
    LOG_DIR="$LOG_DIR" bash log_rotation.sh
    
    [ -f "$LOG_DIR/recent_app.log" ]
    [ ! -f "$LOG_DIR/recent_app.log.gz" ]
}

BATS framework’ünü tanımayan sysadminler için: Bash scriptleri için yazılmış, shell-native bir test framework’ü. Copilot bu testleri üretirken BATS syntax’ını da doğru kullandı.

Gerçek Dünya Senaryosu: Deployment Script Refactoring

Geçen ay 3 yıllık, 800 satırlık bir deployment scriptini refactor etmem gerekti. Script çalışıyordu ama bakımı imkansızdı. Copilot’u şöyle kullandım:

Önce Copilot Chat’e scriptin bir bölümünü yapıştırdım ve “Bu kodu daha modüler hale getir, fonksiyonlara böl, hata yönetimini düzelt” dedim. Çıkan öneriyi inceledim, mantıklı bulduklarımı aldım, almadıklarımı bıraktım.

# Copilot'un önerdiği hata yönetimi pattern'i - bunu benimsedik
set -euo pipefail

handle_error() {
    local exit_code=$?
    local line_number=$1
    echo "HATA: Satır $line_number'da başarısız (exit code: $exit_code)" >&2
    cleanup
    exit "$exit_code"
}

cleanup() {
    # Geçici dosyaları temizle
    [ -d "${TEMP_DIR:-}" ] && rm -rf "$TEMP_DIR"
    # Lock dosyasını kaldır
    [ -f "${LOCK_FILE:-}" ] && rm -f "$LOCK_FILE"
}

trap 'handle_error $LINENO' ERR
trap cleanup EXIT

Bu pattern’i elle yazmak değil ama unutmak kolay. Copilot her seferinde hatırlıyor.

Ekip İçi Kullanım Pratikleri

Birkaç ekiple çalışma deneyimimden öğrendiklerimi paylaşayım:

.copilot-instructions.md dosyası kullanın: Projenizin root’una bu dosyayı koyarsanız Copilot proje standardlarınıza göre öneri veriyor. İçine şunları yazabilirsiniz: kullandığınız shell versiyonu, naming convention’larınız, yasaklı komutlar, zorunlu error handling pattern’leri.

Copilot’u pair programming aracı olarak konumlandırın: Ekibe “bu artık kodunuzu yazıyor” değil “pair programmer’ınız” olarak sunun. Psikolojik fark önemli.

Öneri kabul oranını takip edin: VS Code’da Copilot istatistiklerini görebiliyorsunuz. Ekibinizde bu oran %40’ın altındaysa ya Copilot’u yanlış kullanıyorsunuzdur ya da bağlamı yeterince iyi vermiyorsunuzdur.

Copilot CLI: Terminal Entegrasyonu

VS Code’da çalışmayan, terminalde yaşayan sysadminler için GitHub Copilot CLI ayrı bir seçenek:

# GitHub CLI üzerinden Copilot extension kurulumu
gh extension install github/gh-copilot

# Kullanım örnekleri
gh copilot suggest "nginx loglarında 500 hatalarını say ve IP bazında grupla"

gh copilot explain "awk '{print $9}' access.log | sort | uniq -c | sort -rn"

# Shell alias önerisi
gh copilot suggest -t shell "son 1 saatte en çok CPU kullanan 5 process"

gh copilot suggest komutunun güzel yanı, öneriyi direkt terminale paste edip çalıştırmadan önce inceleme fırsatı veriyor. Kör güven yok, görme fırsatı var.

Copilot’un Sınırları ve Hayal Kırıklıkları

Dürüst olmak gerekirse, Copilot’un bazı konularda ciddi sınırları var:

Çok spesifik versiyon bilgisi: “RHEL 8.9’da systemd-resolved ile dnsmasq çakışması” gibi çok spesifik sorunlarda genellikle yüzeysel kalıyor.

Şirket içi tooling: Kendi yazdığınız araçları, iç API’leri bilmiyor. Bağlamı açıkça sağlamazsanız işe yaramaz öneriler veriyor.

Ağ topolojisi anlayışı: “Bu subnet’teki trafiği şu firewall üzerinden yönlendir” gibi gerçek altyapı kararlarında yetersiz kalıyor.

Çok uzun dosyalar: 500 satırı geçen dosyalarda bağlam kaybı yaşıyor. Uzun script’leri parçalayıp ayrı ayrı çalışmak daha iyi sonuç veriyor.

Sonuç

GitHub Copilot, sysadmin ve DevOps dünyasında gerçek bir verimlilik artışı sağlıyor, ama doğru beklentiyle yaklaşılması şart. Bu araç sizi daha iyi bir sistem yöneticisi yapmıyor, mevcut yetkinliğinizi çarpan etkisiyle büyütüyor. Bash’ı bilmiyorsanız Copilot’un ürettiği Bash’ı kontrol edemezsiniz. Kubernetes’i anlamıyorsanız önerilen manifest’in güvenli olup olmadığını değerlendiremezsiniz.

Günlük iş akışınıza entegre etmek için şu adımlarla başlayabilirsiniz: Önce mevcut projelerinizden birinde deneyin, hafta boyunca kaç öneriyi kabul ettiğinizi not edin, güvenlik açısından riskli gördüğünüz önerileri ekibinizle paylaşın ve zamanla kendi kullanım pattern’lerinizi geliştirin.

Bir araç sonunda sadece bir araç. Vim’in sizi kötü kod yazmaktan alıkoyamadığı gibi, Copilot da sizi kötü karar almaktan koruyamaz. Ama doğru ellerde, doğru beklentiyle kullanıldığında, sabah 9’da başlayıp akşam 6’ya kadar bitiremeyeceğiniz deployment scriptini öğleden önce bitirmenizi sağlayabiliyor. Bu da hiç küçümsenmeyecek bir kazanım.

Bir yanıt yazın

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