Skip to content

Commit

Permalink
Merge pull request #275 from hkan/master
Browse files Browse the repository at this point in the history
Updated Turkish translations
  • Loading branch information
johlym committed Jul 12, 2023
2 parents 6439c83 + e64037e commit f447e5d
Show file tree
Hide file tree
Showing 16 changed files with 124 additions and 125 deletions.
18 changes: 9 additions & 9 deletions content/tr/admin-processes.md
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
## XII. Yönetici Süreci
### Yönetici/yönetim görevlerini tek seferlik işlem olarak çalıştırma
## XII. Yönetim Süreçleri
### Yönetim görevlerini tek seferlik süreçler olarak çalıştırma

[Süreç oluşumu](./concurrency) uygulama çalışırken uygulamanın sıradan işlerini (web isteklerini idare etmek gibi) yapmakta kullanılan süreçlerin bir dizisidir. Ayrı olarak, geliştiriciler çoğunlukla uygulamanın bir kereye mahsus yönetimsel veya bakım görevlerini yapmayı dileyecekler, şunun gibi:
[Süreç formasyonu](./concurrency) uygulama çalışırken uygulamanın sıradan işlerini (web isteklerini idare etmek gibi) yapmakta kullanılan süreçlerin bir dizisidir. Ayrı olarak, geliştiriciler çoğunlukla uygulamanın bir kereye mahsus yönetimsel veya bakım görevlerini yapmayı dileyecekler. Örneğin:

* Veri tabanı göçü çalıştırmak (Django'da `manage.py migrate`, Rails'de `rake db:migrate`).
* Konsolu ([REPL](https://en.wikipedia.org/wiki/Read-eval-print_loop) kabuğu olarakta bilinir), rastgele kodu çalıştırmak veya canlı veritabanına karşılık uygulamanın modellerini denetlemek için çalıştırmak. Çoğu dil hiç bir arguman olmadan (`python` veya `perl`), yorumlayıcı veya bazı durumlarda ayrı komutlarla (Ruby için `irb`, Rails için `rails console`) çalıştırarak bir REPL sağlar.
* Uygulamanın deposuna commit'lenmiş betikleri çalıştırmak (`php scripts/fix_bad_records.php`).
* Veri modelindeki (İng. migrations) değişiklikleri veritabanına yansıtmak (Django'da `manage.py migrate`, Rails'de `rake db:migrate`).
* Herhangi bir kodu çalıştırmak veya canlı yayın veritabanındaki verileri denetlemek için konsolu ([REPL](https://en.wikipedia.org/wiki/Read-eval-print_loop) kabuğu olarak da bilinir) çalıştırmak. Çoğu dil hiçbir argüman olmadan (`python` veya `perl`), veya bazı durumlarda ayrı komutlarla (Ruby için `irb`, Rails için `rails console`) bir REPL sağlar.
* Uygulamanın kod deposundaki betikleri çalıştırmak (`php scripts/fix_bad_records.php`).

Bir kerelik yönetici süreçleri uygulamanın sıradan [uzun çalışan süreçleri](./processes) gibi aynı ortamlarda çalışmalıdır. Onlar herhangi bir sürecin çalıştığı gibi [sürüme](./build-release-run) karşı aynı [kod tabanı](./codebase) ve [yapılandırmayı](./config) kullanarak çalışır. Yönetici uygulama kodunu senkronizasyon sorunundan kaçınmak için yüklemelidir.
Tek sefer çalıştırılması gereken yönetsel işlere ait süreçler de, uygulamanın uzun süre çalışan sıradan [süreçleri](./processes) ile birebir aynı ortamda, aynı [sürümdeki](./build-release-run) [kod tabanı](./codebase) ve [yapılandırmayı](./config) kullanarak çalışmalıdır. Uyum sorunu yaşamamak için, uygulamanın yönetimini sağlayan kod da uygulama ile birlikte geliştirilmeli ve yayınlanmalıdır.

Aynı [bağımlılık yalıtımı](./dependencies) teknikleri bütün süreç yönetiminde kullanılmalıdır. Örneğin, eğer Ruby web süreçleri `bundle exec thin start` komutunu kullanıyorsa, veri tabanı göçü `bundle exec rake db:migrate` komutu kullanmalıdır. Aynı durumda, Virtualenv kullanan bir Python programı, Tornado web sunucusu ve herhangi bir `manage.py` yönetici süreçlerinin ikisini de çalıştırabilmek için `bin/python` kullanmalıdır.
Aynı [bağımlılık yalıtımı](./dependencies) teknikleri bütün süreç tiplerinde kullanılmalıdır. Örneğin, eğer Ruby web süreçleri `bundle exec thin start` komutunu kullanıyorsa, veritabanı göçü de `bundle exec rake db:migrate` komutu kullanmalıdır. Aynı durumda, Virtualenv kullanan bir Python programı, Tornado web sunucusu ve herhangi bir `manage.py` yönetici süreçlerinin ikisini de çalıştırabilmek için `bin/python` kullanmalıdır.

On iki faktör, REPL kabuğunu kural dışı sağlayan ve tek seferlik betikleri çalıştırmayı kolaylaştıran dilleri fazlasıyla destekler. Yerel dağıtımda, geliştiriciler uygulamanın kontrol dizinindeki açık kabuk komutuyla tek seferlik yönetici süreçlerini çalıştırır. Ürün dağıtımında, geliştiriciler bu gibi bir süreci çalıştırmak için ssh veya dağıtımın çalışma ortamı tarafından sağlanan diğer uzak komut çalıştırma mekanizmasını kullanabilir.
On iki faktör, REPL kabuğunu kendisi sağlayan ve tek seferlik betikleri çalıştırmayı kolaylaştıran dilleri fazlasıyla destekler. Yerel dağıtımda, geliştiriciler uygulamanın dizininde doğrudan komut satırında tek seferlik yönetici süreçlerini çalıştırır. Canlı yayın dağıtımında ise, geliştiriciler bu gibi bir süreci çalıştırmak için ssh veya dağıtımın çalışma ortamı tarafından sağlanan diğer uzak komut çalıştırma mekanizmasını kullanabilir.
7 changes: 3 additions & 4 deletions content/tr/background.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,8 @@
Arkaplan
==========

Bu belgeye katkıda bulunan kişiler, yüzlerce uygulamanın geliştirilmesi ve dağıtılmasında doğrudan yer almış, ve dolaylı olarak <a href="https://www.heroku.com/" target="_blank">Heroku</a> platformundaki üzerinde çalıştığımız yüz binlerce uygulamanın geliştirilmesi, çalıştırılması ve ölçeklendirilmesine tanık olmuştur.
Bu belgeye katkıda bulunan kişiler, yüzlerce uygulamanın geliştirilmesi ve yayınlanmasında doğrudan yer almış, ve dolaylı olarak <a href="https://www.heroku.com/" target="_blank">Heroku</a> platformundaki üzerinde çalıştığımız yüz binlerce uygulamanın geliştirilmesi, çalıştırılması ve ölçeklendirilmesine tanık olmuştur.

Bu belge, çok çeşitli yazılım servislerinin, yabancı ortamdaki deneyim ve gözlemlerini birleştirir.
Bu uygulama geliştirimindeki uygun, ideal uygulamalarda bir üçgenleştirme vardır; uygulamanın zamanla olan doğal gelişmesinin, büyümesinin temel etmenlerine dikkat etmek, uygulamanın kod tabanında çalışan yazılımcıların arasındaki işbirliğinin önemli noktaları ve <a href="https://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/" target="_blank">yazılım erozyonunun getirdiği ücretten kaçmak</a>.
Bu belge birçok yazılım servisinde edindiğimiz deneyim ve gözlemlerimizin bir sentezidir. Uygulama geliştirme aşamasındaki ideal pratiklerin, uygulamaların zaman içindeki organik büyüyüşlerine gösterilen özel ilginin, bir uygulamanın kodları üzerinde çalışan geliştiriciler arasındaki işbirliği dinamiklerinin, ve <a href="https://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/" target="_blank">yazılım erozyonunun getirdiği masraftan kaçınmanın</a> toplamı niteliğindedir.

Bizim motivasyonumuz, modern uygulama geliştirmesinde gördüğümüz bazı sistemik problemlerin farkındalığını arttırmak, terimlerle birlikte geniş kavramsal çözüm setleri sağlamak ve bu problemleri tartışmak için ortak bir kelime sunmakdır. Martin Fowler'ın kitabları *<a href="https://books.google.com/books/about/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC" target="_blank">Patterns of Enterprise Application Architecture</a>* ve *<a href="https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C" target="_blank">Refactoring'den</a>* ilham alınmıştır.
Motivasyonumuz modern uygulama geliştirmelerinde gördüğümüz bazı sistemik problemlere olan farkındalığı arttırmak, bahsi geçen problemler için ortak bir terminoloji belirlemek, ve bu problemlere karşı bir dizi çözüm konsepti sunmaktır. Bu konsept oluşturulurken, Martin Fowler'ın kitapları olan *<a href="https://books.google.com/books/about/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC" target="_blank">Patterns of Enterprise Application Architecture</a>* ve *<a href="https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C" target="_blank">Refactoring</a>*'den ilham alınmıştır.
16 changes: 8 additions & 8 deletions content/tr/backing-services.md
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
## IV. Destek servisi
### Destek servislerine ekli kaynak olarak davranma
## IV. Yardımcı servisler
### Yardımcı servisleri iliştirilmiş kaynaklar olarak ele almak

Bir *destek servisi* uygulamanın kendi normal işleminin bir parçası olarak ağ üzerinden tüketim yapan bir servistir. Örnekler veri deposu([MySQL](https://dev.mysql.com/) veya [CouchDB](https://couchdb.apache.org/) gibi), mesajlama/kuyruklama sistemleri( [RabbitMQ](https://www.rabbitmq.com/) veya [Beanstalkd](https://beanstalkd.github.io)), giden email için SMTP servisi([Postfix](https://www.postfix.org/) gibi) ve önbellekleme sistemleri([Memcached](https://memcached.org/) gibi) içerir.
Bir *yardımcı servis* uygulamanın kendi işlevselliğinin bir parçası olarak ağ üzerinden tükettiği herhangi bir servistir. Yardımcı servislere örnek olarak; veritabanları ([MySQL](https://dev.mysql.com/) veya [CouchDB](https://couchdb.apache.org/) gibi), mesajlaşma/kuyruk sistemleri ([RabbitMQ](https://www.rabbitmq.com/) veya [Beanstalkd](https://beanstalkd.github.io)), e-posta göndermek için SMTP servisleri ([Postfix](https://www.postfix.org/) gibi) ve önbellekleme sistemleri ([Memcached](https://memcached.org/) gibi) gösterilebilir.

Destek servisleri, veri tabanı gibi, uygulamaların çalışma zamanlı dağıtımlarında olduğu gibi benzer sistem yöneticileri tarafından geleneksel olarak yönetilirler. Bu yerel yönetilen servislere ilave olarak, uygulama üçüncü parti uygulamalar tarafından onaylanmış ve yönetilmiş servislere sahip olabilirler. Örnekler SMTP servisleri([Postmark](https://postmarkapp.com/) gibi), Metrik toplama servisleri( [New Relic](https://newrelic.com/) veya [Loggly](https://www.loggly.com/) gibi), binary servisler([Amazon S3](https://aws.amazon.com/s3/) gibi) ve API-erişilebilir tüketici servisleri bile [Twitter](https://dev.twitter.com/), [Google Maps](https://code.google.com/apis/maps/index.html), ve [Last.fm](https://www.last.fm/api) gibi) içerir.
Veritabanları gibi yardımcı servisler, geleneksel olarak uygulamayı da yöneten sistem yöneticileri tarafından yönetilirler. Ancak bu yerel servislere ilave olarak, uygulama üçüncü parti uygulamalar tarafından sağlanan ve yönetilen servislere de sahip olabilirler. Bunlardan bazıları; SMTP servisleri ([Postmark](https://postmarkapp.com/) gibi), metrik toplama servisleri ([New Relic](https://newrelic.com/) veya [Loggly](https://www.loggly.com/) gibi), statik içerik barındırma servisleri ([Amazon S3](https://aws.amazon.com/s3/) gibi) ve hatta API-erişilebilir tüketici servisleridir ([Twitter](https://dev.twitter.com/), [Google Maps](https://code.google.com/apis/maps/index.html), ve [Last.fm](https://www.last.fm/api) gibi).

**On iki faktör uygulaması için bu kod, yerel ve üçüncü parti servisler arasında ayrım yapmaz.** Uygulamada, her ikiside ek kaynaktır, [yapılandırmada](./config) saklanmış yer belirleyici/kimlik bilgileri ve URL aracılığıyla erişilir. On iki faktör uygulamasının bir dağıtımı, uygulama kodunda hiçbir değişiklik olmadan üçüncü parti([Amazon RDS](https://aws.amazon.com/rds/) gibi) tarafından yönetilenle yerel MySQL veritabanı silebilmelidir. Aynı şekilde bir yerel SMTP servisi(Postmark gibi), kod değişikliksiz bir üçüncü parti SMTP servisiyle değiş tokuş yapılabilir. Her iki durumda da, kaynak sadece değişmesi gereken yapılandırmada ele alınır.
**On iki faktör uygulamaları için bir servisin yerel veya üçüncü parti olmasının farkı yoktur.** Uygulama için, her ikisi de ek kaynaktır ve [yapılandırmada](./config) saklanmış URL'ler veya yer belirleyici ve kimlik bilgileri ikilisi aracılığıyla erişilir. On iki faktör uygulamasının bir dağıtımı, uygulama kodunda hiçbir değişiklik yapmak zorunda kalmadan yerel bir MySQL veritabanı kullanmaktan üçüncü parti bir veritabanı ([Amazon RDS](https://aws.amazon.com/rds/) gibi) kullanmaya geçebilmelidir. Aynı şekilde yerel bir SMTP servisinden (Postmark gibi), kod değişikliği olmaksızın bir üçüncü parti SMTP servisine geçiş yapılabilir. Her iki durumda da, değişmesi gereken şey sadece yapılandırma ayarlarındaki bağlantı bilgileridir.

Her bir belirgin destek servisi bir *kaynaktır*. Örneğin, bir MySQL veritabanı(Uygulama katmanında parçalanma için kullanılmış) bir kaynaktır; iki MySQL veritabanı iki belirgin kaynak olarak nitelendirilir. On iki faktör uygulaması veritabanlarına, bağlı oldukları dağıtımlara gevşek bağlaşımlarını belirten *ek kaynak* olarak davranır.
Her bir destek servisi bir *kaynaktır*. Örneğin, bir MySQL veritabanı bir kaynaktır; iki MySQL veritabanı (uygulama katmanında parçalanma [İng. sharding] için kullanılan) iki farklı kaynak olarak nitelendirilir. On iki faktör uygulaması bu veritabanlarına, bağlı oldukları dağıtımlara gevşek bağlaşımlarını belirten *ek kaynak* olarak davranır.

<img src="/images/attached-resources.png" class="full" alt="A production deploy attached to four backing services." />
<img src="/images/attached-resources.png" class="full" alt="Canlı yayın dağıtımı dört destek servisine bağlanmış." />

Kaynaklar dağıtımlara istenilen zamanda eklenilip çıkartılabilir. Örneğin, eğer uygulamanın veritabanı donanım sorununa göre yanlış davranıyorsa, uygulamanın yöneticisi son yedeklemeden geri yüklenmiş yeni bir veri tabanı sunucusunu döndürebilir. Şuanki veritabanı ekten çıkarılmış olabilir ve yeni veri tabanı eklenmiş olabilir, hiç bir kod değişikliği olmadan.
Kaynaklar dağıtımlara istenilen zamanda eklenilip çıkartılabilir. Örneğin, eğer uygulamanın veritabanı donanımsal sorunlar yaşıyorsa, uygulamanın yöneticisi son yedeklemeden geri yüklenmiş yeni bir veritabanı sunucusu oluşturabilir. Problemli veritabanının uygulamadan bağlantısı kesilip, yeni veritabanı bağlanabilir, hem de hiçbir kod değişikliği olmadan.
18 changes: 9 additions & 9 deletions content/tr/build-release-run.md
Original file line number Diff line number Diff line change
@@ -1,18 +1,18 @@
## V. Derleme, Sürüm, Çalıştırma
## V. Derleme, yayınlama, çalıştırma
### Derleme ve çalıştırma aşamalarını tam olarak ayırma

Bir [kod tabanı](./codebase) üç aşamada dağıtıma dönüşebilir:
Bir [kod tabanı](./codebase) üç aşamada (geliştirme dağıtımı olmayan) dağıtıma dönüşür:

* *Derleme aşaması* kod deposunun *derleme* olarak bilinen çalıştırılabilir pakette çeviren bir dönüşümdür.Dağıtım süreci tarafından belirlenen bir commit'deki kodun versiyonunu kullanırken, derleme aşaması sağlayıcı [bağımlılıkları](./dependencies) getirir ve binary'leri derler.
* *Sürüm aşaması*, derleme aşaması tarafından üretilmiş derlemeyi alır ve dağıtımı şu anki [yapılandırmasıyla](./config) birleştirir. Son durumda oluşan *sürüm* derleme ve yapılandırmanın ikisinide içerir ve çalışma ortamındaki doğrudan çalıştırma için hazırdır.
* *Çalıştırma evresi* (aynı zamanda "runtime" olarak bilinir) seçili sürümün karşılığındaki uygulamanın [süreçlerini](./processes) bazı setlerini başlatarak, çalıştırma ortamındaki uygulamayı çalıştırır.
* *Derleme aşaması* kod deposunun *derleme* olarak bilinen çalıştırılabilir bir pakete çevrilmesidir. Dağıtım evresi tarafından seçilen commit'teki kod kullanılır. Sistem, üçüncü parti [bağımlılıkları](./dependencies) toparlar ve çalıştırılabilirleri ve statik dosyaları derler.
* *Yayınlama aşaması*, derleme aşaması tarafından üretilmiş derlemeyi alır ve dağıtımı güncel [yapılandırmasıyla](./config) birleştirir. Son durumda oluşan *yayın* derleme ve yapılandırmanın ikisini de içerir ve çalışma ortamında çalıştırmak için hazırdır.
* *Çalıştırma evresi* (aynı zamanda "runtime" olarak bilinir) seçili yayının karşılığındaki [süreçleri](./processes) başlatarak, çalıştırma ortamındaki uygulamayı çalıştırır.

![Kod, sürüm oluşturmak için yapılandırmayla birleşmiş derlemeye dönüşür.](/images/release.png)

**On iki faktör uygulamaları derleme,sürüm ve çalıştırma aşamaları arasında mutlak ayırmayı kullanır.** Örneğin, koddaki değişiklikleri derleme aşamasına geri döndürmenin bir yolu olmadığı için çalışma zamanında kodda değişiklik yapmak imkansızdır.
**On iki faktör uygulamalarının derleme, yayınlama ve çalıştırma aşamaları tamamen birbirinden bağımsızdır.** Örneğin, koddaki değişiklikleri derleme aşamasına geri döndürmenin bir yolu olmadığı için çalışma zamanında kodda değişiklik yapmak imkansızdır.

Dağıtım araçları genel olarak sürüm yönetim araçlarını önerir, en dikkat çekeni bir önceki sürüme geri dönme yeteneğidir. Örneğin, [Capistrano](https://github.com/capistrano/capistrano/wiki) dağıtım aracı sürümleri, şu anki sürümün şimdiki sürüm dizinine bir sembolik link olduğu, `releases` adlı alt dizinde depolar. `rollback` komutu, bir önceki sürüme hızlı geri dönüşü kolaylaştırır.
Dağıtım araçları genelde yayın yönetim araçları da sunar. En dikkat çeken yetenekleri ise bir önceki yayına geri dönebilmeleridir. Örneğin, [Capistrano](https://github.com/capistrano/capistrano/wiki) farklı yayınları `releases` adındaki bir alt dizinde depolar. Çalışıyor olan yayın ise bu alt dizinlerden birine oluşturulmuş bir kısayol dosyasıdır. Capistrano'nun `rollback` komutu, kısayol dosyasının işaret ettiği dizini değiştirerek önceki bir yayına dönüş yapmayı kolaylaştırır.

Her sürüm her zaman sürümlerin zaman damgası gibi (`2011-04-06-20:32:17` gibi) özel sürüm ID'sine veya artış numarasına (`v100` gibi) sahip olmalıdır. Sürümler yalnızca eklemeli bir defterdir ve bir kere oluşturulduğu zaman dönüştürülemez. Herhangi bir değişiklik yeni bir sürüm oluşturmalıdır.
Her yayın zaman damgası gibi (`2011-04-06-20:32:17` gibi) özel bir ID'ye veya her yeni yayında artan bir numaraya (`v100` gibi) sahip olmalıdır. Yayınlar yalnızca eklemeli bir defterdir ve bir kere oluşturulduğu zaman değiştirilemez. Herhangi bir değişiklik yeni bir yayın oluşturmalıdır.

Derlemeler, herhangi bir zamanda yeni kod dağıtıldığında uygulama geliştiricileri tarafından başlatılır. Çalışma zamanı yürütmesi, kontras tarafından, sunucu tekrar çalıştırılması veya çökmüş süreçlerin süreç yöneticisi tarafından tekrar başlatılması gibi durumlarda otomatik olarak olabilir. Bunun sonucunda, çalıştırma evresi, gecenin bir yarısında çalışan geliştiriciler yokken uygulamanın çalışmasını engelleyen problemler uygulamanın bozulmasına yol açabildiği için, olabildiği kadar az sayıda hareketli bölüm olarak tutulmalıdır. Derleme evresinde, hatalar dağıtımı çalıştıran geliştiriciler için her zaman ön planda olduğu için daha fazla karış olabilir.
Derlemeler, geliştiricilerin kod değişikliklerini kod depolarına yüklemesiyle başlatılır. Çalıştırma evresi ise, sunucuların yeniden başlatılması veya çökmüş süreçlerin tekrar ayağa kaldırılması gibi durumlarda otomatik olarak gerçekleştirilir. Bu yüzden çalıştırma evresi olabildiği kadar az sayıda hareketli parçaya sahip olmalıdır ki, gecenin bir yarısında, işinin başında olan hiçbir geliştirici yokken bozulmasın. Derleme evresi ise daha karmaşık olabilir, çünkü hatalar dağıtımı çalıştıran geliştiricilerin her zaman önündedir.
Loading

0 comments on commit f447e5d

Please sign in to comment.