Android uygulama yayın hesabı sahipliği, yalnızca mağazaya ilk yüklemeyi kimin yapacağını belirleyen teknik bir ayrıntı değildir; uygulamanın gelecekte kim tarafından güncellenebileceğini, firma değişikliğinin ne kadar sorunsuz gerçekleşeceğini ve kritik erişimlerin kimde kalacağını doğrudan etkiler. Bu nedenle geliştirme firmasını değerlendirirken kod kalitesi kadar Play Console hesabının sahipliği, imzalama düzeni, kaynak kod deposu, harici servis hesapları ve sürüm çıkarma süreci de teklifin parçası olmalıdır. Sağlıklı modelde müşteri şirket kritik varlıkların kontrolünü korur, geliştirme firması ise işini yapmaya yetecek tanımlı yetkilerle çalışır.

01

Yayın ve teknik sahiplik neden şirket kontrolünde kalmalı?

Temel ilke, uygulamanın ticari ve operasyonel kontrolünün müşteri şirkette kalmasıdır. Geliştirme firması projeyi üretebilir, yayına hazırlayabilir ve sürümleri yönetebilir; ancak yayın hesabının, kaynak kodun ve kritik erişimlerin yalnızca tedarikçinin kişisel ya da kurumsal hesaplarına bağlı olması firma değişimini gereksiz biçimde zorlaştırır. Buradaki amaç ajansa güvenmemek değil, uygulamayı tek bir hizmet sağlayıcıya bağımlı olmayan kurumsal bir varlık olarak yönetmektir.

Sahiplik ile operasyon yetkisini birbirinden ayırın

Hesabın sahibi olmak ile günlük yayın operasyonunu yürütmek aynı şey değildir. Şirket, hesap ve varlık sahipliğini korurken geliştirme ekibine gerekli uygulama düzeyinde veya hesap düzeyinde erişimleri verebilir. Bu yaklaşım, mobil uygulama firmalarını karşılaştırırken teknik yeterlilik kadar yönetişim modelini de değerlendirmeyi mümkün kılar. Firma değişse bile temel dijital varlıklar kurumun kontrolünde kalır.

  • Google Play geliştirici hesabının kurumsal kontrolünü tanımlayın.
  • Kaynak kod deposunun kime ait olduğunu sözleşmede belirtin.
  • İmzalama ve yayın erişimlerini ayrı sorumluluklar olarak ele alın.
  • Harici servis hesaplarını mümkün olduğunca şirket adına açın.
  • Tedarikçi erişimlerinin proje rolüne göre sınırlandırılmasını isteyin.
Programlar insanlar tarafından okunmak için yazılmalıdır. - Harold Abelson ve Gerald Jay Sussman
02

Uygulama hangi Google Play hesabından yayımlanmalı?

Kurumsal bir Android projesinde tercih edilen model, uygulamanın müşteri şirketin kontrolündeki Play Console hesabından yayımlanmasıdır. Google Play Console hesap sahibi, yönetici ve kullanıcı gibi farklı erişim düzeyleri sunar; bu nedenle geliştirme firmasının uygulamayı yayımlayabilmesi için hesabın sahibi olması gerekmez. Firma, ihtiyaç duyduğu yetkilerle kullanıcı veya yönetici olarak davet edilebilir. Google’ın güncel yardım dokümanları da hesap sahibi ile diğer erişim seviyelerini ayrı tanımlar.

Tedarikçinin hesabından yayın ne zaman risk oluşturur?

Uygulama yalnızca ajansın geliştirici hesabında bulunuyorsa operasyonel bağımlılık oluşabilir. İleride şirket içi ekip kurulması, yeni yazılım firmasına geçilmesi veya kurumsal yeniden yapılanma yaşanması halinde hesap ve uygulama devri ayrıca yönetilmek zorunda kalır. Google Play, geliştirici hesabı sahipliği ve uygulama sahipliği için resmi aktarım süreçleri sunar; ancak satın alma aşamasında doğru hesap yapısını kurmak, sonradan devir ihtiyacını azaltır.

  • Uygulamanın hangi geliştirici hesabından yayımlanacağını teklifte yazdırın.
  • Hesap sahibinin şirket içindeki sorumlu kişi veya yapı olmasını planlayın.
  • Ajansa verilecek erişim seviyesini görev bazında tanımlayın.
  • Kişisel e-posta hesaplarına bağımlı kritik sahiplik yapısından kaçının.
  • Firma değişiminde erişim kaldırma prosedürünü önceden belirleyin.
03

İmzalama anahtarı yönetimi nasıl kurgulanmalı?

İmzalama düzeni, uygulamanın gelecekte güncellenebilmesi için yazılı ve denetlenebilir biçimde kurulmalıdır. Play App Signing kullanıldığında Google Play, son kullanıcılara dağıtılan uygulamaları imzalamak için uygulama imzalama anahtarını yönetir; geliştirici tarafında ise mağazaya gönderilen paketin doğrulanmasında kullanılan ayrı bir yükleme anahtarı bulunur. Bu iki anahtarı aynı şey gibi değerlendirmek, teklif ve devir belgelerinde ciddi belirsizlik yaratabilir.

Şirket hangi bilgileri kontrol altında tutmalı?

Şirketin yalnızca bir keystore dosyası teslim alması yeterli değildir. Hangi anahtarın ne amaçla kullanıldığı, dosyanın nerede saklandığı, erişim yetkisinin kimlerde olduğu, sertifika parmak izlerinin hangi servislerde kayıtlı bulunduğu ve anahtar değişikliği gerektiğinde izlenecek süreç de belgelenmelidir. Özellikle Firebase, harita servisleri, kimlik doğrulama veya API sağlayıcıları imza sertifikası bilgilerine bağlıysa bu bağımlılıklar teknik devir listesinde görünmelidir.

  • Play App Signing kullanılıp kullanılmadığını açıkça kaydedin.
  • Uygulama imzalama anahtarı ile yükleme anahtarını ayırın.
  • Yükleme anahtarının güvenli saklama sorumluluğunu belirleyin.
  • Sertifika parmak izlerinin kullanıldığı servisleri listeleyin.
  • Anahtar yenileme veya erişim kaybı senaryosunu belgelendirin.
  • Tek kişinin bildiği parola ve dosya düzeninden kaçının.
04

Uygulama erişim yetkileri firmaya nasıl verilmelidir?

Geliştirme firmasına sahiplik devretmek yerine görevini yapmasına yetecek kontrollü erişim verilmelidir. Play Console’da kullanıcıların tüm hesaba veya yalnızca belirli uygulamalara erişimi ayrıştırılabildiği için yayın, test, mağaza içeriği veya raporlama gibi görevler ihtiyaç kadar yetkilendirilebilir. Böylece proje ekibi operasyonu sürdürebilirken şirket kritik hesap kontrolünü kaybetmez. Google Play’in kullanıcı ve izin modeli, erişimlerin hesap ve uygulama düzeyinde yönetilebildiğini açıkça belirtir.

En az yetki yaklaşımı neden önemlidir?

Ajansa gereksiz geniş erişim vermek kadar, işi yapamayacağı kadar dar yetki vermek de operasyonu aksatır. Bu nedenle teklif öncesinde hangi ekip rolünün hangi sisteme erişeceği çıkarılmalıdır. Play Console dışında kaynak kod deposu, CI/CD sistemi, bulut hesabı, analitik, bildirim altyapısı ve üçüncü taraf API panelleri de aynı mantıkla ele alınmalıdır. kurumsal mobil uygulama güvenliği için sorulacak sorular bu erişim modelinin güvenlik boyutunu değerlendirmede tamamlayıcı bir çerçeve sunar.

  • Her sistem için sahip, yönetici ve operasyon kullanıcılarını belirleyin.
  • Ortak kullanılan tek parola yerine kişisel yetkilendirme kullanın.
  • Ayrılan ekip üyelerinin erişimini hızla kaldırabilecek yapı kurun.
  • Üretim ve test ortamı yetkilerini gerektiğinde ayırın.
  • Kritik hesaplarda çok faktörlü doğrulamayı kurumsal süreç haline getirin.
05

Kaynak kod ve servis erişimleri ne zaman teslim edilmeli?

Kaynak kod teslimi yalnızca projenin sonunda verilen bir ZIP dosyası olarak görülmemelidir. Daha sürdürülebilir model, kod deposunun mümkünse baştan müşteri şirketin kontrolündeki organizasyonda açılması ve geliştirme firmasına proje boyunca erişim verilmesidir. Bu mümkün değilse sözleşmede belirli kilometre taşlarında eksiksiz depo aktarımı, sürüm geçmişi, bağımlılıklar ve yapılandırma belgeleri açıkça tanımlanmalıdır. Böylece teknik teslim, ödeme tamamlandığında ilk kez görülen belirsiz bir kalem olmaktan çıkar.

Teslim listesinde yalnızca kaynak kod bulunmamalı

Yeni bir ekip uygulamayı devraldığında kodun yanında çalışır geliştirme ortamına, servis yapılandırmalarına ve yayın prosedürüne de ihtiyaç duyar. Bu nedenle kurumsal mobil uygulama geliştirme sürecini değerlendirirken teslim kriterleri baştan planlanmalıdır. Kullanılan bulut servisleri, bildirim altyapısı, analitik hesapları, API anahtarlarının yönetim yeri, ortam değişkenleri ve uygulama paketleme adımları devir dokümanının parçası olmalıdır.

  • Tam kaynak kod deposunu ve sürüm geçmişini teslim kapsamına alın.
  • Geliştirme, test ve üretim yapılandırmalarını ayrı belgeleyin.
  • Üçüncü taraf servis hesaplarının sahipliğini ve erişimlerini listeleyin.
  • Derleme için gerekli bağımlılık ve ortam gereksinimlerini kaydedin.
  • CI/CD veya otomatik yayın süreçlerinin erişimlerini teslim edin.
  • Teknik dokümantasyonun güncel sürümle eşleşmesini şart koşun.
06

Sürüm çıkarma süreci nasıl belgelenmeli ve test edilmeli?

İyi bir devir dokümanı, yeni bir geliştiricinin sıfırdan tahmin yürütmeden test sürümü oluşturup mağaza paketini hazırlayabilmesini sağlamalıdır. Bunun için kullanılan geliştirme araçları, uygulamanın paket kimliği, derleme varyantları, ortam değişkenleri, imzalama adımları ve mağazaya yükleme sırası açık biçimde yazılmalıdır. Belgenin yalnızca teorik olması yeterli değildir; teslim öncesinde şirket içinden veya projeye daha önce dahil olmamış bir teknik kişinin yönergeleri izleyerek derleme yapabilmesi güçlü bir doğrulama yöntemidir.

Yayın akışını tekrar edilebilir hale getirin

Sürüm çıkarma sürecinin tek bir geliştiricinin bilgisayarına veya hatırladığı komutlara bağlı olması operasyonel risktir. Mümkün olduğunda derleme ve dağıtım adımlarının standartlaştırılması, yetkilerin merkezi biçimde yönetilmesi ve sürüm notlarının kayıt altına alınması gerekir. mobil uygulama geliştirme sürecini planlama aşamasında bu yayın mimarisinin de proje teslim kriterleri arasında ele alınması, sonraki güncellemeleri daha öngörülebilir hale getirir.

  • Derleme komutlarını ve gerekli araç sürümlerini belgeleyin.
  • Test ve üretim yapılandırmalarının farklarını açıklayın.
  • Mağaza paketinin nasıl oluşturulduğunu adım adım yazın.
  • Sürüm numarası ve sürüm notu yönetimini standartlaştırın.
  • Yayın öncesi kontrol listesini teslim dokümanına ekleyin.
  • Devir öncesinde bağımsız bir yeniden derleme testi yapın.
07

Firma değiştiğinde yeni ekip güncelleme yayımlayabilir mi?

Doğru sahiplik ve devir modeli kurulmuşsa yeni ekip uygulamayı geliştirmeye ve güncelleme yayımlamaya devam edebilmelidir. Bunun için şirketin Play Console kontrolü, güncel kaynak kodu, derleme bilgileri, yükleme anahtarı erişimi ve uygulamanın bağlı olduğu servis hesapları elinde olmalıdır. Play App Signing kullanılan projelerde uygulama imzalama anahtarı Google Play tarafından yönetildiğinden, yeni ekibin temel ihtiyacı doğru hesap yetkileri ve geçerli yükleme sürecidir.

Devir senaryosunu sözleşmeden önce prova edin

Aday firmalara “Bugün başka bir ekibe geçersek uygulamayı güncellemek için hangi varlıkları teslim edeceksiniz?” sorusunu yöneltmek çok değerlidir. Yanıtın yalnızca “kaynak kodu veririz” düzeyinde kalmaması gerekir. Gerekli hesaplar, anahtarlar, yapılandırmalar, mağaza yetkileri ve teknik dokümantasyon birlikte tanımlanmalıdır. Hesap sahipliğinin gerçekten değişmesi gereken durumlarda Google Play’in resmi sahiplik aktarım akışının kullanılması gerekir; resmi olmayan devir yöntemlerinden kaçınılmalıdır.

  • Yeni ekibin Play Console’a nasıl erişeceğini önceden tanımlayın.
  • Güncel kaynak kodun eksiksiz kopyasını kurumda bulundurun.
  • Yükleme anahtarı ve gerekli gizli bilgilerin erişimini planlayın.
  • Harici servislerde yönetici değişikliğinin nasıl yapılacağını belgeleyin.
  • Devir sonunda eski firmanın erişimlerini kapatacak kontrol listesi oluşturun.
08

Mağaza süreci ve sonraki sürümler teklife dahil mi?

İlk geliştirme, ilk mağaza yayını, mağaza geri bildirimlerine teknik yanıt, sonraki sürümler ve bakım aynı hizmet kalemi değildir. Bir teklif yalnızca uygulamanın kodlanmasını kapsayabilir; başka bir teklif ilk yayın sürecini, politika veya teknik geri bildirimlere göre düzeltmeleri ve belirli bir destek dönemini de içerebilir. Bu nedenle fiyatı karşılaştırmadan önce hangi yayın sorumluluklarının kapsamda olduğunu aynı senaryo üzerinden aday firmalara yazılı olarak sormak gerekir.

Android bakım teklifini ayrı kapsam olarak okuyun

Bakım hizmeti; işletim sistemi değişikliklerine uyum, bağımlılık güncellemeleri, hata düzeltmeleri, güvenlik iyileştirmeleri, mağaza gereksinimlerine uyarlama ve yeni özellik geliştirme gibi farklı işleri içerebilir. Bunların hepsi otomatik olarak ilk proje bedeline dahil kabul edilmemelidir. mobil uygulama tekliflerini kapsam, sözleşme ve sahiplik açısından karşılaştırırken yayın sonrası hizmetlerin ayrı maddeler halinde gösterilmesi daha sağlıklı değerlendirme sağlar.

  • İlk Play Console yayınının teklife dahil olup olmadığını sorun.
  • Mağaza geri bildirimlerine yapılacak düzeltmelerin kapsamını tanımlayın.
  • Sonraki sürümlerin nasıl fiyatlandırılacağını ve talep edileceğini netleştirin.
  • Bakım ile yeni özellik geliştirmeyi ayrı hizmet olarak tanımlayın.
  • Acil hata müdahalesi ve normal güncelleme sürecini birbirinden ayırın.
  • Destek sona erdiğinde yapılacak teknik devri sözleşmeye ekleyin.
09

Android firma tekliflerini hangi sahiplik kriterleriyle seçmeli?

Firma seçiminde en sağlıklı karşılaştırma, tüm adaylara aynı yayın ve devir senaryosunu yazılı olarak sordurmaktır. “Uygulama hangi hesaptan yayımlanacak, imzalama düzeni nasıl kurulacak, kaynak kod ne zaman teslim edilecek, başka bir ekip güncelleme yapabilecek mi ve yayın sonrası hizmetler neleri kapsıyor?” soruları fiyat teklifinin yanına eklenmelidir. Böylece düşük veya yüksek teklifin arkasındaki gerçek operasyon kapsamı görünür hale gelir.

Sözleşmede ölçülebilir teslim maddeleri arayın

“Tüm erişimler teslim edilir” gibi genel ifadeler yerine hangi hesabın, hangi rolün, hangi teknik dosyanın ve hangi dokümanın teslim edileceği listelenmelidir. Uygulamanın şirket için uzun ömürlü bir dijital varlık olması hedefleniyorsa, yayın hesabı sahipliği ile teknik devir maddeleri proje kabul kriterleri kadar somut olmalıdır. İyi bir teklif, yalnızca uygulamayı geliştirmeyi değil, yeni bir ekibin makul bir geçişle devam edebilmesini de mümkün kılan yönetişim düzenini tarif eder.

  • Yayın hesabının şirket kontrolünde kalıp kalmadığını karşılaştırın.
  • İmzalama ve anahtar yönetimi dokümantasyonunu teklif maddesi yapın.
  • Kaynak kod ve servis erişimi teslim zamanını açıkça belirleyin.
  • Firma değişiminde güncelleme yayımlama senaryosunu yazılı test edin.
  • İlk yayın, sonraki sürümler ve bakım kapsamını ayrı değerlendirin.
  • Sözleşme bitiminde erişim kaldırma ve devir prosedürünü tanımlayın.

Android Teklifinizde Yayın ve Devir Kapsamını Netleştirin

Aldığınız Android geliştirme teklifindeki yayın hesabı, imzalama, kaynak kod ve devir maddelerini paylaşın; teslim kapsamını birlikte değerlendirelim.

Teklifinizi Değerlendirelim