Marketing Ops as Code: GitHub’da Nasıl Kurulur?
GitHub Blog’da yayımlanan bir yazıda, GitHub’ın Japonya ve Kore pazarlama operasyonlarını yürüten Tomoko Tanaka, etkinlik yönetiminin tekrar eden kısmını tamamen GitHub üzerine taşıdığı bir kurulumu anlatıyor. Sonuç şu: Daha önce elle bir-iki güne yayılan etkinlik hazırlığı, tek bir GitHub Issue’dan başlayarak kendi kendini kuruyor, her sabah kayıtları tarıyor ve etkinlik bitince toparlama işini kendisi yapıyor. Bu yazıda kurulumun hangi yapı taşlarına dayandığını, hangi güvenlik önlemlerinin işe yaradığını ve benzer bir akışı kendi tekrarlayan işiniz için nasıl ölçeklendirebileceğinizi özetliyoruz.
Sorun: Karar değil, karardan sonrası
Tanaka’nın anlattığına göre asıl zorlayan kısım “hangi konu, hangi kitle” sorusu değil. Etkinlik onaylandıktan sonra başlayan sabit sıra:
- Etkinlik platformunda bir landing page’in kopyalanması,
- Her kanal için belirli formatta UTM etiketli bağlantı setinin üretilmesi,
- Davet e-postasının hazırlanması ve gönderen ekibe talep açılması,
- Etkinliğin iki ayrı project board’a eklenmesi,
- Etkinliğe kadar her sabah kayıt listesinin indirilip temizlenmesi ve paydaşlara durum paylaşılması,
- Etkinlik sonrası katılımcı listesinin dışa aktarılması, CRM yüklemesi için yeniden biçimlendirilmesi, kayıtların etiketlenmesi ve rapor yazılması.
Tek tek bakıldığında hiçbiri zor değil. Ama yazıda vurgulandığı gibi bu adımlar yanlış bağlantı yapıştırmak, bir günü atlamak ya da 15 rapora girdi olan bir kampanya adını yanlış yazmak için birebir fırsat. Tanaka’nın eski kariyeri Linux sunucularında kurumsal müşteriler için veritabanı yönetmek; kod yazma alışkanlığı paslanmış olsa da otomasyona uygun bir pipeline’ı görebildiğini söylüyor. Kodu kendisi yazmamış: Runbook’larını yazıya dökmüş, GitHub Copilot‘a vermiş ve otomasyonu sohbet içinde büyütmüş.
Sistemin üç yapı taşı: Issue form, label, Actions
Temel fikir yeni değil; GitHub’daki pazarlama ekiplerinde zaten her proje için bir GitHub Issue açma alışkanlığı varmış. Plan, tartışma ve durum aynı yerde yaşıyor. Tanaka’nın yaptığı şey, bu issue’yu işin kendisini yapar hale getirmek olmuş. Sistem üç GitHub bileşenine dayanıyor:
Issue form = başvuru formu
Boş bir metin kutusu yerine issue form yapılandırılmış alanlar sunuyor: etkinlik başlığı, tarih, bölge, kampanya adı, hedef kitle. Webinar ve yüz yüze etkinlik gibi her etkinlik tipi için ayrı bir form var, hepsi aynı mekanizmayı besliyor.
Label = anahtar
event-setup gibi bir label burada sadece bir etiket değil, tetikleyici. Her otomasyon iş akışı “yalnızca bu label varsa çalış” koşuluyla başlıyor.
Actions = makine
GitHub Actions iş akışları label eklendiğinde devreye giriyor, issue gövdesindeki form alanlarını ayrıştırıyor ve işi yapıyor. Bir repository’nin geliştiriciye sunduğu her şey (geçmiş, görünürlük, inceleme ve her karar için bir URL) pazarlama akışına ücretsiz geliyor.
Bunu mümkün kılan tek teknik ön koşul, kullanılan araçların script’lenebilir bir arayüz sunması. Etkinlik yönetim platformu bir API sunuyor; CRM tarafında ise resmî CLI yapılan işlerin tamamını kapsadığı için API anahtarı yapılandırılmamış bile — CLI tarayıcı üzerinden oturum açıp kimlik doğrulamayı kendisi hallediyor. Yazının argümanı da bu: API ya da CLI, hangisi olursa olsun, tekrarlayan işiniz script’lenebilir bir araçtan geçiyorsa aynı desen sizin için de geçerli.
“Hazır pazarlama otomasyonu varken neden?” sorusuna cevap
Yazıda beklenen itiraz doğrudan karşılanıyor: Pazarlama otomasyon platformları zaten var ve iyi bir tanesi bu işlerin bir kısmını kutudan çıktığı gibi karşılayabilir. Ancak APAC tek bir pazar değil, birbirinden hayli farklı pazarların toplamı; aynı ekip içinde bile iş akışları alt bölgeye ve segmente göre değişiyor. Aynı webinar bir ay Tokyo için Japonca, ertesi ay Seul için Korece yapılabiliyor — farklı segmentler, CRM’de farklı alanlar ve “iyi lead” için farklı bir tanım.
Paketli bir aracın bu varyasyonların tamamını sindirmesi ise özelleştirme bütçesi, danışmanlık saati ve başkasının yol haritasını beklemek anlamına geliyor. Kendi araçlarıyla kurmanın avantajı şu: İş akışı değişikliği bir pull request’e dönüşüyor. İstenen şey tarif ediliyor, bir reviewer kontrol ediyor ve değişiklik yazılım geliştiricilerin kullandığı sürecin aynısıyla main branch’e iniyor.
Pipeline bir sohbetle başlıyor
Akış, issue oluşmadan önce başlıyor. Tanaka GitHub Copilot’ı açıp kabaca “Kasımda AI destekli geliştirme üzerine bir webinar yapmak istiyorum” diyor. Sonrasını repository kökündeki AGENTS.md dosyası şekillendiriyor. Bu dosya, düz Markdown ile yazılmış ekip runbook’u: Kampanyaların nasıl adlandırıldığını, mali çeyreklerin tarihlere nasıl eşlendiğini, her bölgenin hangi saat dilimini kullandığını ve iyi bir davet e-postasının neye benzediğini tanımlıyor. GitHub Copilot bu dosyayı okuyup benzer bir geçmiş etkinliği buluyor, adlandırma kurallarına uyan bir kampanya adı öneriyor, davet e-postasının iki versiyonunu taslak olarak yazıyor ve runbook’un sorulmasını söylediği soruları soruyor.
Pipeline’ın başına bir sohbet koymak bilinçli bir tasarım kararı ve iki sorunu aynı anda çözüyor. Her şeyi otomatikleştirirseniz esnekliği kaybediyorsunuz; bu etkinliğin biraz farklı olmasını istediğiniz gün katı bir pipeline’da bunu söyleyecek yer yok. Her şeyi insana bırakırsanız hata alıyorsunuz. Sohbet tam ortada duruyor: GitHub Copilot şablonu takip ettiği için issue’ya doğru veri doğru formatta düşüyor; sohbet olduğu için de tek bir etkinliğin ayrıntıları, alt taraftaki mekanizma kırılmadan esnetilebiliyor.
Başlangıçta bu sohbet terminalde, GitHub Copilot CLI üzerinde gerçekleşiyormuş. Yazara göre bu kendisi için sorun değil ama “terminal aç” birçok kişi için bir engel. GitHub Copilot uygulaması ile aynı sohbet artık normal bir masaüstü penceresinde yapılıyor; giriş bariyeri “shell’de rahat olmak”tan “yazabilmek”e inmiş.
İş bölümü konusunda yazıda net bir sınır çiziliyor: GitHub Copilot taslak yazar, karar insana aittir. Her kampanya adı, her e-posta konu satırı ve her tarih, hiçbir şey hareket etmeden önce onaydan geçiyor. Sohbetin sonunda GitHub Copilot issue’yu doğru label’larla açıyor ve makineler devralıyor.
Tek label, tamamen kurulmuş bir etkinlik
event-setup label’ı issue’ya düştüğü anda bir GitHub Actions iş akışı devreye giriyor ve eskiden günün büyük bölümünü alan işi birkaç dakikada yapıyor:
- Etkinlik platformunda geçmiş bir etkinliği kopyalayarak yeni landing page’i oluşturuyor,
- Kanal başına bir tane olmak üzere, her seferinde tutarlı formatta UTM etiketli URL setinin tamamını üretiyor,
- Davet e-postasını Word belgesi olarak hazırlayıp repository’ye commit ediyor,
- E-posta gönderen ve bölgesel pazarlamayı takip eden ekiplerle talep issue’ları açıyor,
- Etkinliği project board’lara ekleyip alanları dolduruyor,
- Issue’ya özet bir yorum bırakıyor; böylece issue’yu açan bir sonraki kişi her şeyi tek yerde görüyor.
Kayıt taraması ise label yerine zamanlamayla çalışıyor. Her sabah cron ile tetiklenen bir iş akışı, açık her etkinlik için en güncel kayıtları çekiyor ve temizlenmiş listeyi paylaşıyor. Davetli etkinliklerde bekleme listesini de kriterlere göre süzüyor: Kayıt olan kişi kurumsal bir hesapta çalışan bir geliştirici mi, öğrenci mi, yoksa executive briefing’e katılmayı çok isteyen bir rakip mi?
Tanaka’nın en çok gurur duyduğunu söylediği tasarım kararı ise tek bir açma/kapama anahtarı: DRY_RUN. GitHub terminolojisiyle bir repository variable olarak saklanan bu ayarı her iş akışı çalışmadan önce kontrol ediyor. Açık olduğunda tüm iş akışları hiçbir dış sisteme dokunmadan adımları yürütüyor: Landing page oluşmuyor, başka repository’lerde issue açılmıyor, liste paylaşılmıyor. Kendi işini otomatikleştiren bir pazarlama ekibi için prova imkânı şart; DRY_RUN tam olarak o prova anahtarı ve yazara göre deney yapmaktan hiç çekinmemesinin nedeni.
Etkinlik sonrası: Slash komutları ve SKILL.md
Katılımcı listesini dışa aktarmak, CRM yüklemesi için sütunları yeniden biçimlendirmek, şirket adlarını hesap kayıtlarıyla eşleştirmek ve raporu yazmak eskiden işin en kötü kısmıymış. Şimdi iki komut:
/lead-upload: Katılımcı listesini çekiyor, pazarlama operasyonları ekibinin CRM yüklemesi için ihtiyaç duyduğu kesin formata dönüştürüyor, talep issue’şunu açıyor ve takip issue’larını kapatıyor./event-report: Katılım metriklerini ve anket sonuçlarını toplayıp raporu etkinlik issue’suna yorum olarak ekliyor; yani etkinliğe dair her şeyin yaşadığı tek URL’ye geri dönüyor.
Bunlar GitHub Copilot agent skill’leri ve yazının en çok altını çizdiği nokta şu: Bir skill aslında bir Markdown dosyası. Her biri bir SKILL.md; GitHub Copilot’a ne yapacağını, hangi sırayla yapacağını ve neye dikkat etmesi gerektiğini düz metinle anlatan yazılı bir prosedür. Tanaka’nın skill’leri kafasında tuttuğu runbook’lar gibi okunuyor, çünkü zaten o runbook’lar. Yazıdaki özet cümle net: Runbook yazabiliyorsanız skill de yazabilirsiniz.
Skill’ler aynı zamanda sistemi esnek tutan unsur. APAC bölgesinde iki pazar takip sürecini birebir aynı yürütmüyor; kitleler, segmentler ve yerel alışkanlıklar farklı. Sabit kodlanmış bir iş akışı her pazarı tek bir kalıba zorlardı. Markdown’la yazılmış bir prosedür ise esnek: Her pazar, altındaki mekanizmaya dokunmadan runbook’u kendi gerçekliğine uyarlayabiliyor. Etkinlik sonrası adımların sabit pipeline yerine skill’lerde yaşamasının nedeni tam olarak bu.
Skill’ler bir yönüyle kod gibi ele alınıyor: Yenileri pull request ile geliyor ve merge edilmeden önce inceleniyor; CODEOWNERS dosyası incelemeyi ilgili maintainer’a yönlendiriyor. Yani onay süreci olan bir pazarlama otomasyonu — yönetişim de platformla birlikte hazır geliyor.
Güvenlik önlemleri deneme cesareti veriyor
Yazar, müşteri verisine ve API kimlik bilgilerine dokunan bir iş akışını, tüm ekibin görebildiği bir repository’de, neredeyse hiç kod yazmadan otomatikleştirdiğini söylüyor; altı ay önce bu kombinasyona “pervasızlık” diyeceğini de ekliyor. Fikrini değiştiren şey, daha o gelmeden yerinde duran güvenlik önlemlerinin sayısı olmuş.
Kendi eklediği önlemler tanıdık geliştirici alışkanlıkları: DRY_RUN anahtarı, her pull request’te çalışan bir test suite ve her değişiklik için code review. Bunların yazılımı koruduğu kadar pazarlama işini de koruduğu görülmüş. Platformla birlikte gelen iki önlem ise daha kritik:
- Push protection ile secret scanning. Bu pozisyondaki biri için kâbus senaryosu, yanlışlıkla bir API token’ı commit etmek. GitHub’ın push protection özelliği, secret repository’ye düşmeden push’u engelliyor; GitHub’ın kendi token’larında ise sızan bir token otomatik olarak iptal ediliyor.
- GitHub Copilot’ın veri politikaları. Kayıt listeleri iş verisi ve sabit script’ler bunları sabit biçimde işliyor. Ama gerçek iş hiçbir zaman tamamen sabit değil; bazı günler hiçbir script’in öngörmediği tek seferlik bir veri kesiti gerekiyor. GitHub Copilot’ın business planlarında prompt’lar saklanmadığı ve model eğitiminde kullanılmadığı için bu tek seferlik analiz doğrudan istenebiliyor — sektörde birçok kişinin sessizce yaptığı gibi iş verisini yan sekmedeki tüketici sohbet botuna yapıştırmak yerine. Aynısı modeller için de geçerli: Hangi modellerin kullanılabileceği kişisel takdire değil organizasyon politikasına bağlı, dolayısıyla tek seferlik bir deney bile şirketin önceden belirlediği sınırlar içinde çalışıyor.
Skill’lerin yan etkisi olarak ortaya çıkan bir avantaj daha var: Her prosedür artık adlandırılmış ve sabit bir iş birimi olduğu için, organizasyonun onayladığı model listesinden işe uygun model seçilebiliyor. Günlük liste temizliğini hızlı ve düşük maliyetli bir model yapıyor; kampanya metnini daha güçlü bir model yazıyor.
Yazıda dürüst bir başarısızlık da paylaşılıyor: Sabahki tarama iş akışı bir kez sessizce başarısız olmuş ve listelerin bayatladığını kimse beş gün boyunca fark etmemiş. İzlenmeyen otomasyon, gecikmeli bir saatli bomba. Çıkarılan ders net: Zamanlanmış her iş akışına, gözden kaçmayacak şekilde yüksek sesle şikâyet edebileceği bir yol bırakın.
Nereden başlamalı?
Tanaka’nın önerisi mütevazı bir adımla başlıyor: Haftanızdaki en çok tekrar eden tek işi seçin. Sonra o işin dokunduğu araçların API’si ya da CLI’si olup olmadığına bakın — kaçının olduğu şaşırtabilir.
Ardından mümkün olan en küçük sürümü kurun: Girdileri toplayan bir issue form, “başla” anlamına gelen bir label ve işin tek bir adımını yapan bir Action. Ya da doğrudan runbook’unuzu SKILL.md olarak yazıp GitHub Copilot’a çalıştırtın. Güvenene kadar dry-run anahtarıyla çalıştırın, sonra büyütün.
Yazının kapanış cümlesi de özeti veriyor: Kod yazılmadı; zaten bilinen şey, yani işin nasıl yapıldığı yazıya döküldü ve gerisini platform hallettiği. Sizin “her sabahki kayıt listeniz” her neyse, muhtemelen yazıya dökülmüş tek bir runbook mesafesinde.
Kaynaklar ve İleri Okuma
- Marketing ops as code: Automating events from planning to follow-up on GitHub (Tomoko Tanaka, The GitHub Blog)
- GitHub Docs: Issue form söz dizimi
- GitHub Actions dokümantasyonu
- GitHub Copilot dokümantasyonu
- I automated my job (and it made me a better leader)
- Copilot cloud agent ile kırık Actions işini tek tıkta çözmek
- Copilot CLI ile GitHub Pages’e custom domain bağlama
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder