şükela:  tümü | bugün
  • yuksek sayida sunucuyu yoneten kurumlarda, operations departmaninin islerini otomatize etmek veya kolaylastirmak icin yazilim gelistiren departman.

    sistem yoneticileri, network yoneticileri ve sre'ler bu grubun musterisidir.
  • (bkz: chef)
    (bkz: puppet)

    (bkz: http://devopsweekly.com/)

    edit 1 : unutmadan, kapısında "devops" yazılı bir takımınız olmadan da yazılım projeniz bal gibi olabilir, nitekim devops son 4 yılda ortaya çıkmış bir "etikettir". yazılım geliştirmenin ve bolca haraket eden parçası bulunan sistemleri kontrol etmenin iyice zorlaştığı günümüzde doğrusu "devops olmadan verimli bir yazılım projesi olmaz" olmalıdır...

    edit 2 : gözden kaçan verim kelimesi vurgulandı...
  • development ve systems engineering arasında entegrasyon ve organizasyon sağlanmasını amaçlayan yazılım geliştirme metodudur. devops diye bir vasıf olmaz. ama birçok firma bu işten sorumlu elemanının / takımın görev tanımı için bu kelimeyi kullanır.

    devops'cular tercihen yazılım geliştirme ve sistem yönetimi alanlarının her ikisinde de tecrübe sahibi insanlardır. ne iş yaptığı sorulduğunda kem küm eder, "bilgisayar falan işleri" diye kestirip atabilir. tedbirli yaklaşılırsa ve kesinlikle ukalalık yapılmazsa artık -bi' zahmet- iyi olur. puppet, chef aws gibi tool'lar iki günde öğrenilip çocuk oyuncağına çevrilmesi pek kolay şeylerdir. ama olay iki program kullanmak değil. artistliğin lüzumu yok. sonra şu nasıldı bu nasıldı diye zaten bize geliyorsunuz. çarparım.
  • kadın yazılımcı blog yazarlarından elif kuş, devfest women etkinliğinde devops üzerine bir sunum yaptı. ilgilenler şuradan sunuma erişebilir.
  • development and operations lafının, her boku kısaltmaya meraklı amerikanyalılar tarafından kısaltılmış halidir.
  • devops ile ilgili hemen hemen herşeyi (hatta ötesi) etiketlenmiş bir şekilde tek bir yerden ulaşabileceğiniz adres,

    http://www.devopsbookmarks.com/
  • 3-4 haziran'da tr'de ilk defa yapılacak olan organizasyon için,

    http://devopsdays.istanbul/
  • yaklaşık olarak 7 aydır görev yaptığım, macerası bol ama zor pozisyon.

    'devops bir title değil, bir kültürdür' olayına katılmadığımı söyleyim öncelikle. yönetim de sadece yöneticiyle değil takımla da ilgili bir olay mesela, ama 'yöneticilik bir title değildir' demek ne kadar saçma olacaksa, bence bu da öyle. devops herşeyden önce bir kültür evet, bir teknikler bütünü - bir sistematik, ve hatta bir sorun çözme biçimi. bir disiplin yani. ve her disiplin gibi, onu iyi anlamış, doğru uygulayan ve çevresindekilere doğru şekilde öğreten insanlara ihtiyaç duyuyor. bu da gayet önemli bir 'title' demek.

    ha evet, tabii ki kapısında 'devops' yazan bir ekip olmadan da çok güzel işlere imza atabilirsiniz, ama bu demek değildir ki 'devops' pratiklerine ihtiyacınız yok veya onları uygulamıyorsunuz.

    devops, benim için, otomasyon sanatı olsa gerek. her programcı bir şeyleri otomatize etmiyor mu diyebiliriz, ama bu çok daha geniş bir otomasyon. altyapının, networkün, makinelerin, işlerin, insanların ve süreçlerin otomasyonundan bahsediyoruz. hepsinin kendi içinde de değil, birbirleriyle etkileşimin otomasyonu.

    'geliştiricinin yaptığı commit, yayındaki web sitesine nasıl gidecek?'

    * committen önce, bu commitin yapılmasına sebep olan iş nereden ve nasıl geldi? nasıl tanımlandı? ekip, ihtiyacı olan şeyi geliştiriciye doğru şekilde aktarabildi mi?
    * geliştirici commiti nerede ve nasıl yaptı? önünde hazır bir development ortamı var mıydı? bu ortamı nasıl kurdu? bu ortamın hatasız ve istendiği gibi olduğundan emin miyiz? her geliştiricinin önünde aynı ortam olduğuna emin miyiz? bu ortamın, canlı yayın ortamını yeterli şekilde yansıttığından emin miyiz?
    * geliştirici bu commiti nereye gönderdi? bir git hosting mi satın aldık yoksa kendimiz mi kurduk? bu git alanı üzerinde yetkiler doğru tanımlanmış mı? aynı anda çeşitli geliştiricilerden çok sayıda commit geldiğinde, birbirlerine karışmadan ve sağlıklı şekilde süreç devam edebiliyor mu?
    * commit geldi, kalitesinden emin miyiz? otomatik testlere giriyor mu - giriyorsa nasıl giriyor? test patlarsa noluyor? ekipteki diğer kişiler tarafından kalite kontrolünden geçirildi mi?
    * herşey tamam, commitin kalitesinden eminiz, işi açan kişi, iş tanımının karşılandığını ve gerekli geliştirmenin hakkıyla yapıldığını düşünüyor mu?
    * bu özellik sitedeki başka herhangi bir şeye zarar veriyor mu? (bu tek cümle, kocaman bir qa sürecinin özeti aslında.) bunun cevabını alabilmek için tabi, commitle gelen değişikliği nasıl bir test ortamında ve ne şekilde yayına aldığınız şeklinde bambaşka dinamikler içeren bir süreci incelemek gerekiyor.
    * commit depoya kabul edildi;
    ** bu commit, geliştiricilerin günlük düzeninde önemli bir değişiklik yaratıyor mu? yaratıyorsa, nasıl bir bilgilendirme yapmalı?
    ** bu commit, daha önce stackte olmayan yeni bir araç gerektiriyor mu? bu araç nedir, nasıl kurulur, nasıl ayarlanır? yayındaki siteye zarar vermeden nasıl yayına dahil edilir?
    ** bu commit, veritabanında bir değişiklik gerektiriyor mu? bu değişiklikler, yayındaki web sitesine zarar vermeden nasıl uygulanır? bu değişiklikler, geliştiricilerin önündeki ortama nasıl uygulanır?
    * tüm gerekli değişiklikler tespit edildi ve bilgilendirmeler yapıldı, bu değişiklikler yayındaki websitesine nasıl yansıtılacak? (hey gidi koca 'deployment')

    hepsini bitirdik, geliştiricinin yazdığı kod yayına girdi. bir de o yayındaki sitelerin nasıl bir performansla çalıştığı, ayakta kalıp kalamadığı, farklı yükler altında nasıl davrandığı vs. konular var ki içinden çıkılmaz, kısa kesiyorum.

    bunların hepsini yapabilmek için de bazen geliştirici, bazen sistemci, bazen sre, arada dba, kimi zaman networkçü olmanız gerekiyor. öyle puppet ya da chef implemente etmekle olan bir iş değil yani. hatta en uyuz olduğum şey, devops'un araçlardan ibaret bir iş sanılması. otomasyondan konuşuyorsak, otomasyonu sağlayacak aracın hayati önemi olduğu doğru, ancak buradaki en önemli 'araç' insanın ta kendisi.

    ha bir de herkesin her konuda fikri olması durumu var. biri gelir 'olm siz docker kullanmazsanız olmaz o iş' der, biri gelir 'abi <insert çıkalı 3 gün olmuş teknoloji here> muhteşem ya nasıl kullanmazsın manyak mısın' der. bir ara herşeyin mikroservise dönüşmesi gerektiğini savunan bir dünya insan vardı, neyse şükür ki zamanla azaldılar. ya bu teknoloji/yöntemlerin hepsi, kendi içlerinde gayet güzel şeyler olabilir ama hali hazırda çalışan bir altyapı söz konusu ise, onun nasıl çalıştığını anlamadan, araştırmadan, bilmeden üstüne 'x kullanmalıyız çünkü bu ara çok hype' kafasıyla etrafa tavsiyeler yağdırmak, ne bileyim işte üzülüyorum... ucu sistem yönetimine dokunan bir alanda nasıl hype-driven iş yapılabildiğini de aklım almıyor, javascript kütüphanesi mi yahu bu?

    özet olarak, stres altında çalıştığınızda insanı hayatından soğutabilecek, ama doğru şartlarda bi o kadar da keyif vermesi mümkün ve çılgın miktarda yeni bilgi edinmeyi sağlayan/gerektiren bir alan. yalnız, ekosisteme hakim değilseniz çok can yakan bir learning curve'i var. etrafınız, naptığını biliyormuş gibi davranan insanlarla doluyken sizin hiçbir şey anlamıyor olmanız insanı salak gibi hissettiriyor ama inanın onlar da çok anlamıyor, detaylara pek takılmıyorlar sadece.

    öyleyken böyle sözlük. çok dolmuşum.
  • (bkz: onur salgit)