Projeler büyüdükçe operasyonlar artıyor, operasyonları koda döktükçe komutlar, parametreler artıyor. Bunları yardımcı bir scriptle kontrol altına alabiliriz.

Yazının sonunda bu yönteme dair eleştirim ve alternatif önerim var.

Bir projede frontend geliştiricisinin her bildiğini backend geliştirici bilmek, backend geliştiricisinin her bildiğini devops takımı bilmek zorunda değil. Ve farklı pozisyondaki geliştiricilerin birbirlerini aynı konular için sürekli meşgul etmemesi arzu edilir. Bunun için süreçleri olabildiğince belgelemek ve otomatikleştirmek gerekiyor.

Basit bir amacım var.

1. Birisi bana alanımla ilgili bir soru sorduğunda, ona olabildiğince basit bir cevap vermek istiyorum.
2. Bana soru sorulmadan önce de olası çözümleri kendi bulmayı denesin istiyorum.
3. Proje neyle yazılmış olursa olsun, yöntem hep aynı olsun istiyorum.

Örneğin…

Soru: Geliştirme ortamımı nasıl ayağa kaldırabilirim?
Cevap: Bağımlılıkları kur, do start komutunu çalıştır. Daha fazla bilgi için wiki bakabilirsin.

Soru: Son değişiklikleri geliştirme ortamıma aldım; ancak backend sunucusu çalışmamaya başladı.
Cevap: Veritabanı tablosunda değişiklik yaptım, do build && do restart komutunu çalıştır.

Soru: Çevirileri güncelledim; ancak arayüzde değişiklikleri göremiyorum.
Cevap: do update_translations komutunu çalıştır. do yardım çıktısına bir göz at, wiki’ye de yazdım.

Neden Shell scripting?

Nedenini şurada yazmıştım. BASH zaten projelerimin çoğunda bir bağımlılık olarak geliyor. İkincisi, shell programlama hem öğrenmesi basit, hem derlemeye gerek kalmadığı için kodlaması zaman kazandırıyor. Yeni bir komut ihtiyacı olduğunda bir fonksiyon ekleyip denemek kolay oluyor. Basit bir örnek üzerinden gidelim:

#!/usr/bin/env bash

BLUE="\\033[1;34m"
GREEN="\\033[1;32m"
NORMAL="\\033[0;39m"
RED="\\033[1;31m"

print_help() {
    echo -e "${BLUE}Available environments${NORMAL}"
    echo "  - DEV (default)"
    echo "  - PROD"
    echo "  - STAGING"
    echo ""
    echo -e "${BLUE}Available commands${NORMAL}"
    echo -e "  > colors \t\t Show available colors."
    echo -e "  > tell [:words] \t Tell me something."
}

colors() {
    echo ""
    echo "This is a test command."
    echo -e "${BLUE}BLUE${NORMAL} - ${GREEN}GREEN${NORMAL} - ${RED}RED${NORMAL}"
}

tell() {
    echo -e "${GREEN}${HOSTNAME}:${NORMAL} [email protected]".
}

if [ -z "$1" ]
then
    print_help
else
    case $ENV in
        "PROD")
            env_str="production"
            ;;
        "STAGING")
            env_str="staging"
            ;;
        *)
            env_str="development"
            ;;
    esac
    echo -e "${BLUE}Environment:${NORMAL} $env_str"
    "[email protected]"
fi

# terminal
$ ENV=PROD ./do.sh tell "hello, world!"
Environment: production
URRAS: hello, world!.

Komutu biraz daha kısaltmak için alias kullanabiliriz:

# ~/.bashrc
alias do="ENV=DEV ./do.sh"

# Windows kullanıyorsanız, aşağıdakini deneyin.
# alias do="ENV=DEV winpty bash do.sh"

# terminal
$ do colors
Environment: development

This is a test command.
BLUE - GREEN - RED

Biraz daha işe yarar örnekler GitHubGist‘te bulabilirsiniz:

# terminal
$ do
Available environments
  - DEV (default)
  - PROD
  - STAGING

Available commands
  > build                Build or rebuild services
  > django [:command]    Run a django-specific command
  > docker [:command]    Run a docker command
  > logs [:service]      View output from containers
  > runserver            Run development server
  > shell                Connect to a BASH session from the service inside
  > start                Create and start containers
  > status               List containers
  > stop                 Stop services

Problemler

Her yeni projenin altında bir do.sh dosyası oluşturmak, projeye özel olmayan kodların bakımı açısından sıkıntılı bir durum. Stiller ve çalışma biçimiyle ilgili yeni bir standart oluşturmak istediğimde, bu değişiklikleri tüm projelere tek tek yansıtmam gerekiyor. Bu nedenle, başka bir komut satırı uygulaması yazıp, bu uygulamayla do.yaml gibi bir ayar dosyasını okumak daha mantıklı olabilir. Böylece projeye özel olmayan kodları dışarıda tutmuş oluruz.

Peki yok mu böyle bir şey zaten? Elbette var, Sup bu mantıkta çalışıyor. Golang ile yazılmış olmasının avantajı, işletim sisteminize göre komut satırı uygulaması içeren bir binary indirip, basit bir ayar dosyası oluşturup hemen kullanmaya başlayabilmeniz. Oldukça kapsamlı ve güzel bir uygulama, mutlaka denemenizi öneriyorum. Eğer gereksiz karmaşık gelirse benim bu yazıda değindiğim yönteme bakabilirsiniz.

Bir diğer problem, PowerShell kullananlar için ayrı bir script dosyası hazırlamak zorunda olmanız. Bu konuda çözüm önerileriniz olursa sevinirim.