Back-end tarafında yapılan geliştirmeler testing ortamına deploy olana kadar bazı durumlarda front-end uygulamalarını engelliyor. Bu durumda Front-end ekibi de geliştirme yapamıyor.
Çözüm denemeleri: Bu durumu çözmek için mock data, docker, ngrok gibi yöntemler denedim. Mock Data çok uğraştırıcı olduğu için ngrok denemeye çalıştım. Ngrok’ta çok sağlıklı değil çünkü her seferinde local ortamdan sunucumu çalıştırıp front-end ekibine veriyorum. Front-end’in bana da bağlı kalmaması için Docker kurulumu yaptım ve uygulamamı ayağı kaldırdım. Burada uygulamanın çok geç build olduğunu gördüm. Front-end ekibi her seferinde branch değiştirip build almaya kalkarsa yaklaşık 10 dakika beklemek zorunda kalıyor.
Bu sorunun doğru çözümü docker mı? Değilse alternatifleri neler olabilir?
Her defasında 10 dakika beklemeniz doğru bir containerfile stratejisi izlemiyor olabileceğinizi düşündürttü.
Geliştirme pratiklerinizde ufak iyileştirmeler gerekiyor olabilir. Örneğin, staging ortamına ve hatta production’a çıktığınızda yaptığınız geliştirmeler, mümkünse yayındaki bir şeyi bozmamalı ve geliştirme akışını engellememeli. Tabi her zaman öyle olmuyor.
Heroku kullanıyorsanız review app’i inceleyebilirsiniz. İstediğiniz branch için ayrı bir ortam oluşturmanızı tek-tıkla sağlıyor. İşiniz bittikten sonra da silebilirsiniz. Böylece merge’lenmeyi bekleyen bir sürü PR olmaz.
Diyelim ki kullanmıyorsunuz, ve yeni bir ortamda(staging ve prod hariç) da uygulamayı ayağa kaldırmak istemiyorsunuz. (cd gibi bir pipeline ekleyip, elle trigger ettiğinizde size istediğiniz branch’i bir yere deploy edecekken… Yine de insanın elinden gelmediği durumlar olabilir)
Diğer geliştirici bireyin uygulamayı ayağa kaldıracak kadar bilgisinin olması. Burada illa build edilmiş bir imaj vermemize gerek yok aslında. Bazı yöntemler:
Pek sevmediğim bir yöntem: Github veya Gitlab kullanıyorsanız PR/MR review süreci tamamlandığında trigger edilen bir job yazarak, container image’ını oluşturmak. Eğer front-end uygulamasını geliştiren arkadaş hazırda beklemiyorsa, çok uzun süreceğini sanmıyorum. Ardından docker-compose ile geliştirme ortamında kullanabilir.
Tek bir container imajı ve volume kullanmak. Branch’i değiştirip, docker run komutunun(ve schema load’un) çalıştırması. Redis, PostgreSQL vb gereken servislerin çalışıyor ve doğru versiyonda olduğunu var sayıyoruz. Bi de sidekiq için worker’ları ayağa kaldırması lazım olabilir. (her defasında docker’ı build etmemize gerek yok, app dizinini yereldeki volume’a bağlayabiliriz. )
docker-compose kullanılması, volume üzerinden local sistemi bağlayıp git üzerinden branch’i değiştirip, ardından db’yi kullanılabilir hale(belki drop, belki seed, belki schema:load) getirecek bir script yazılabilir.
Uygulamayı ayağa kaldıracak basit bir script. PostgreSQL’i ve redis’i ayağa kaldıracak, Database’leri drop edecek, create edecek, schema’yı db’ye yükleyecek, uygulamayı koşacak. Hatta branch değiştirmeyi bile buna yaptırtabiliriz.
Dikkat edilecek şeyler:
PostgreSQL versiyonunu gibi uygulamanın istenildiği şekilde çalışmasını engelleyecek nedenlerden dolayı docker-compose kullanmak iyi olabilir.
Her branch değişikliğinde database istediğimiz gibi çalışmayabilir.
DB’yi droplayıp, tekrar create edebiliriz. Ardından direkt schema:load çalıştırmak işimizi görür.
Droplamak da zaman kaybına neden olabileceğinden test verisi oluşturmak için seed kullanılabilir.
