Indonesian Translation

content/id/admin-processes.md

@@ -0,0 +1,14 @@
+## XII. Proses administrasi
+### Jalankan administrasi/manajemen sebagai proses satu kali
+
+[Formasi proses](./concurrency) adalah larik proses yang digunakan untuk melakukan bisnis reguler aplikasi (seperti menangani permintaan web) saat dijalankan. Secara terpisah, pengembang sering kali ingin melakukan tugas administratif atau pemeliharaan satu kali untuk aplikasi, seperti:
+
+* Menjalankan migrasi basis data (misal. `manage.py migrate` di Django, `rake db:migrate` di Rails).
+* Menjalankan konsol (juga dikenal sebagai shell [REPL](http://en.wikipedia.org/wiki/Read-eval-print_loop)) untuk menjalankan kode arbitrer atau memeriksa model aplikasi terhadap database langsung. Sebagian besar bahasa menyediakan REPL dengan menjalankan juru bahasa tanpa argumen apa pun (misal. `python` atau `perl`) atau dalam beberapa kasus memiliki perintah terpisah (misal. `irb` untuk Ruby, `rails console` untuk Rails).
+* Menjalankan skrip satu kali yang dilakukan ke dalam repo aplikasi (misal. `php scripts/fix_bad_records.php`).
+
+Proses admin satu kali harus dijalankan di lingkungan yang identik dengan [proses yang berjalan lama](./proses) reguler aplikasi. Mereka menjalankan [release](./build-release-run), menggunakan [codebase](./basis kode) dan [config](./config) yang sama dengan proses apa pun yang dijalankan terhadap rilis itu. Kode admin harus dikirimkan bersama kode aplikasi untuk menghindari masalah sinkronisasi.
+
+Teknik [dependency isolation](./dependensi) yang sama harus digunakan pada semua jenis proses. Misalnya, jika proses web Ruby menggunakan perintah `bundle exec thin start`, maka migrasi basis data harus menggunakan `bundle exec rake db:migrate`. Demikian pula, program Python yang menggunakan Virtualenv harus menggunakan `bin/python` vendor untuk menjalankan server web Tornado dan proses admin `manage.py` apa pun.
+
+Dua belas faktor sangat menyukai bahasa yang menyediakan shell REPL di luar kotak, dan yang membuatnya mudah untuk menjalankan skrip satu kali. Dalam penerapan lokal, pengembang menjalankan proses admin satu kali dengan perintah shell langsung di dalam direktori checkout aplikasi. Dalam penerapan produksi, pengembang dapat menggunakan ssh atau mekanisme eksekusi perintah jarak jauh lainnya yang disediakan oleh lingkungan eksekusi penerapan tersebut untuk menjalankan proses tersebut.

content/id/background.md

@@ -0,0 +1,8 @@
+Latar belakang
+==========
+
+Kontributor dokumen ini telah terlibat langsung dalam pengembangan dan penerapan ratusan aplikasi, dan secara tidak langsung menyaksikan pengembangan, pengoperasian, dan penskalaan ratusan ribu aplikasi melalui pekerjaan kami di <a href="http://www.heroku.com/" target="_blank">platform Heroku</a>.
+
+Dokumen ini menyatukan semua pengalaman dan pengamatan kami pada berbagai macam aplikasi perangkat lunak sebagai layanan di alam liar. Ini adalah triangulasi praktik ideal untuk pengembangan aplikasi, memberikan perhatian khusus pada dinamika pertumbuhan organik aplikasi dari waktu ke waktu, dinamika kolaborasi antara pengembang yang mengerjakan basis kode aplikasi, dan <a href="http://blog.heroku.com/archives/2011/6/28/the_new_heroku_4_erosion_resistance_explicit_contracts/" target="_blank">menghindari biaya erosi perangkat lunak</a>.
+
+Motivasi kami adalah untuk meningkatkan kesadaran akan beberapa masalah sistemik yang telah kami lihat dalam pengembangan aplikasi modern, untuk menyediakan kosa kata bersama untuk membahas masalah tersebut, dan untuk menawarkan serangkaian solusi konseptual yang luas untuk masalah tersebut dengan terminologi yang menyertainya. Formatnya terinspirasi dari buku Martin Fowler *<a href="https://books.google.com/books/about/Patterns_of_enterprise_application_archi.html?id=FyWZt5DdvFkC" target="_blank">Pola Arsitektur Aplikasi Perusahaan</a >* dan *<a href="https://books.google.com/books/about/Refactoring.html?id=1MsETFPD3I0C" target="_blank">Refactoring</a>*.

content/id/backing-services.md

@@ -0,0 +1,15 @@
+## IV. Layanan beking
+### Perlakukan layanan beking sebagai sumber daya menempel
+
+Sebuah *Layanan beking* adalah layanan yang app makan melalui jaringan sebgai bagian dari operasi normalnya. contoh pemuatan datastore (seperti[MySQL](http://dev.mysql.com/) atau [CouchDB](http://couchdb.apache.org/)), sistem layanan/antrian (seperti [RabbitMQ](http://www.rabbitmq.com/) atau [Beanstalkd](https://beanstalkd.github.io)), layanan untuk email keluar (seperti[Postfix](http://www.postfix.org/)), dan sistem cache (seperti [Memcached](http://memcached.org/)).
+
+Layanan beking seperti basisdata diatur secara tradisional oleh system administrator yang sama yang menerapkan app runtime. Layanan ini bisa ditambah secara lokal, app juga dapat memilki layanan yang disediakan oleh pihak ketiga. contoh Layanan SMTP  (seperti[Postmark](http://postmarkapp.com/)), Layanan pengumpulan metrik (seperti [New Relic](http://newrelic.com/) atau [Loggly](http://www.loggly.com/)), layanan aset binary (seperti [Amazon S3](http://aws.amazon.com/s3/)), dan  even layanan API untuk konsumen (seperti[Twitter](http://dev.twitter.com/), [Google Maps](https://developers.google.com/maps/), atau [Last.fm](http://www.last.fm/api)).
+
+**kode untuk duabelas faktor app tidak membedakan antara layanan lokal dan pihak ketiga** untuk aplikasi, kedaunya merupakan sumberdaya menempel, diakses menggunakan URL atau locator/kredensial lain yang disimpan di [config](./config). sebuah [deploy](./codebase) dari duabelas faktor app harus dapat menukar local mysql database dengan pihak ketiga (seperti [Amazon RDS](http://aws.amazon.com/rds/)) tanpa perubahan di kode app. sehingga server SMTP lokal dapat ditukar dengan layanan SMTP pihak ketiga (seperti postmark) tanpa perubahan kode. di kedua kasus, hanya handle sumber daya pada konfig yang perlu diubah.
+
+Setiap layanan beking yang berbeda merupakan *sumber daya*. contohnya, sebuah basis data MySQL adalah sebuah sumber daya; dua database (digunakan untuk sharding di layer aplikasi) dianggap sebagai dua sumber daya yang berbeda. dua belas faktor app memperlakukan kedua basis data sebagai *sumber daya menempel*, yang mengindikasi loose coupling ke tempat deploy yang menempel.
+
+<img src="/images/attached-resources.png" class="full" alt="Penerapan produksi yang dilampirkan ke empat layanan beking." />
+
+Sumber daya dapat ditempel and dilepas dari deploy semaunya. contohnya jika basis data berlaku aneh karena masalah hardware, administrator app akan membuat server basis data baru yang berisi restore dari backup paling baru. basis data produksi saat ini dapat dilepas dan basis data baru ditempel -- semuanya tanpa perubahan kode.
+

content/id/build-release-run.md

@@ -0,0 +1,20 @@
+## V. Build, release, run
+### Pisahkan dengan ketat antara tahap build dan run
+
+A [codebase](./codebase) ditransformasikan ke dalam deploy (non-development) melalui tiga tahap:
+
+* *tahap build* adalah transformasi yang mengkonversi sebuah repo kode ke sebuah bundel executable yang disebut sebagai sebuah *build* menggunakan sebuah versi dari code yang dicommit spesifik oleh proses deployment, tahap build mengambil vendors [dependencies](./dependencies) dfan mengkompilasi binaries dan asset.
+* *tahap release* mengambil build yang diproduksi pada tahap build dan mengkombinasikan dengan deploy [config](./config). yang menghasilkan *release* yang terdiri dari build dan config dan siap untuk diekekusi pada lingkungan eksekusi.
+* *tahap run* (disebut juga sebagai "runtime") menjalankan app pada lingkungan eksekusi, dengan men-launch beberapa set dari [processes](./processes) app dari release terpilih.
+
+![kode menjadi sebuah build, yang dikombinasikan dengan config untuk menciptakan sebuah release](/images/release.png)
+
+
+**duabelas faktor app menggunakan pemisahan ketat antara build, release, dan run** sebagai contoh, tidak mungkin untuk membaut perubahan pada kode saat runtime, karena tidak ada cara untuk menularkan perubahan tersebut seperti di tahap build.
+
+kakas deployment biasanya menyediakan kakas manajamen, yang sering digunakan adalah kemampuan untuk kemabli ke release sebelumnya. sebagai contoh, kakas [Capistrano](https://github.com/capistrano/capistrano/wiki) menyimpan releqase ke dalam sebuah subdirectory bernama `releases`, yang mana release saat ini adalah symlink ke direktori release saat ini. perintah `rollback` membuat hal tersebut mudah untuk kembali ke release sebelumnya.
+
+Setiap release harus memiliki ID release yang unik, seperti timestamp dari release (seperti `2011-04-06-20:32:17`) atau angka yang meningkat (seperti `v100`). release adalah jurnal yang hanya bisa ditambah dan release tidak bisa diubah sekali itu diciptakan. perubahan harus menciptakan release yang baru.
+
+Build diinisiasi oleh developer app setiap kali kode baru dideploy. eksekusi runtime, kontransya, dapat terjadi otomatis dalam beberapa kasus misalkan seperti pada reboot server, atau process crash saat direstart oleh process manager, tahap run sebisa mungkin terdiri dari bagian bergerak sesedikit mungkin, karena persoalan yang mencegah app dari berjalan normal dapat terjadi di tengah malam saat tidak ada developer yang dapat hadir. tahap build dapat menjadi lebih kompleks, karena error selalu ada di foreground untuk developer yang melakukan deploy.
+

content/id/codebase.md

@@ -0,0 +1,19 @@
+## I. codebase
+### Satu codebase dilacak dalam kendali revisi, banyak deploy
+
+Sebuah duabelas-faktor app selalu terlacak dalam sebuah sistem kendali revisi, semacam [Git](http://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), atau [Subversion](http://subversion.apache.org/). sebuah salinan dari basis data pelacakan versi dikenal sebagai *code repository* atau hanya *repo*.
+
+suatu *codebase* adalah sebuah repo (dalam sebuah sistem kendali revisi terpusat seperti Suberversion), atau dari set repo yang berbagai sebuat akar commit (dalam sebuah sistem kendali revisi terpisah seperti Git).
+
+![satu codebase terpetakan ke banyak terapan](/images/codebase-deploys.png)
+
+selalu ada korelasi satu ke satu antara codebase dan app.
+
+* Jika ada banyak codebase, maka itu bukanlah sebuah app -- itu adalah sistem terdistribusi. Setiap komponen dalam sebuah sistem terdistribusi adalah sebuah app, dan setiap app tersebut dapat secara individual comply dengan duabelas-faktor.
+* app berbeda yang berbagi kode yang sama adalah sebuah pelanggaran dari duabelas-faktor. solusi untuk persoalan ini dengan menerapkan kode yang dipakai app berbeda tersebut ke dalam libraries yang diikutkan melalui [manajer dependency](./dependencies).
+
+Hanya ada satu codebase per app, namun akan ada banyak penerapan dari sebuah app. sebuah *deploy* adalah instansiasi berjalan dari sebuah app. Hal ini umum diterapkan sebuah situs produksi dan di satu atau beberapa situs percobaan. Tambahan lain, setiap developer memiliki sebuah salinan dari app yang berjalan di lingkyungan pengembangan lokal masing-masing, setiap dari itu dapat dianggap sebagai sebuah deploy.
+
+Codebase sama untuk seluruh deploy, walaupun terdapat versi berbeda yang aktif di setiap deploy. contohnya, seorang developer mungkin memiliki beberapa commit yang belum terdeploy untuk percobaan; percobaan memiliki beberapa commit yang tidak ter-deploy untuk produksi. Tetapi semua berbagi codebase yang sama, sehingga dapat diartikan teridentifikasi sebgai deloy yang berbeda dari sebuah app yang sama.
+
+

content/id/concurrency.md

@@ -0,0 +1,17 @@
+## VIII. Konkurensi
+### Meningkat melalui model proses 
+
+Suatu program komputer, sekali dijalankan, akan direpresentasikan dengan satu atau lebih proses. aplikasi web telah menjadi salah satu variasi dari bentuk eksekusi proses, contohnya proses PHP berjalan sebagai proses anak dari Apache, dimulai sesui permintaan berdasarkan kebutuhan volume request. Proses Java menggunakan pendekatan yang berbeda, dengan JVM menyediakan proses besar yang me-reserve suatu large block dari system resource (CPU dan memory ) pada startup, dengan konkurensi diatur secara internal melalui thread. di kedua kasus, proses yang berjalan hanya minimal terlihat ke developer dari app.
+
+![skala diekspresikan dengan proses yang berjalan,  workload yang berbeda-beda diekspresikan dengan tipe proses.]
+(/images/process-types.png)
+
+**Pada dua belas faktor app, proses merupakan masyarakat kelas satu** proses pada dua belas faktor app merujuk pada [the unix process model for running service daemons](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Menggunakan model ini developer dapat mengarstik app untuk menangani workload yang beragam dengan men-assign setiap tipe dari pekerjaan ke sebuah *tipe proses*. contohnya, permintaan HTTP dapat ditangani dengan sebuah proses web, dan task yang berjalan panjang di latar belakang oleh proses pekerja.
+
+ini tidak mengeluarkan proses individual dari menangani multiplexing internal, melalui thread dalan runtime VM, atau model async/event yagn ditemukan pada kakas seperti [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](http://twistedmatrix.com/trac/), atau [Node.js](http://nodejs.org/). namun setiap VM individual dapat tumbuh sangat besar (skala vertical), sehingga aplikasi harus dapat mengembang ke banyak proses berjalan di banyak mesin fisik.
+
+Model proses benar bersrinar ketika saat untuk meningkat. [share-nothing, horizontally partitionable nature of twelve-factor app processes](./processes) berarti menambah konkurensi tambahan sebagai operasi yang sederhana dan dapat diandalkan. array dari tipe proses dan nomor dari proses tiap tipe yang disebut sebagai *process formation*. 
+
+dua belas faktor app proses [Seharusnya tidak akan pernah daemonize](http://dustin.github.com/2010/02/28/running-processes.html) atau menulis PID files. sebaliknya, bergantung pada proses manager di sistem operasi (seperti [systemd](https://www.freedesktop.org/wiki/Software/systemd/), manajer proses tersebar pada cloud platform, atau kakas seperti [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) pada pengembangan) untuk mengatur [output streams](./logs), merespon proses yang crash, dan menagani restart dan shutdown yang diinisiasi user.
+
+

content/id/config.md

@@ -0,0 +1,24 @@
+## III. Konfig
+### Simpan konfig di Environment
+
+Konfig milik suatu app merupakan segalamnya yang akan berbeda setiap [deploys](./codebase)(staging, production, developer environments, dll). Hal ini termasuk :
+
+* Resource yang menangani basisdata, memcached, dan lainnya [backing services](./backing-services)
+* kredensila ke layanan eksternal seperti Amazon S3 atau Twitter
+* Setiap nilai per deploy seperti hostname untuk deploy
+
+App seringkali menyimpan konfig sebagai konstan di kode. Hal ini merupakan pelanggaran dari duabelas-faktor, yang membutuhkan **pemisahan tegas untuk konfig dari kode**. konfig secara substantif beragam untuk semua deploy, sedangkan kode tidak.
+
+Sebuah tes litmus untuk mengetahui apakah sebuah app memiliki konfig yang telah dikeluarkan dari kode dengan cara jika codebase bisa dijadikan open source saat itu juga, tanpa membuka kredensial apa pun.
+
+Catatan untuk definisi "config" **tidak** termasuk konfig internal aplikasi, seperti `config/routes.rb` di rails atau or bagaimana [modul kode tersambung](http://docs.spring.io/spring/docs/current/spring-framework-reference/html/beans.html) pada [Spring](http://spring.io/).  Tipe config yang tidak bervariasi untuk deploy, sehingga lebih baik dilakukan di dalam kode.
+
+pendekatan lain untuk konfig adlaah menggunakan file konfig yang tidak dimasukkan ke dalan kendali revisi, seperti `config/database.yml` pada Rails. Hal ini merupakan peningkatan besar daripada menggunakan constant yang dimasukkan ke dalam repo kode, namun memiliki kelemahan: mudah untuk memasukan file konfig ke repo; ada kecenderungan untuk file konfig tersebar di berbagai tempat dengan berbagai format, membuat hal tersebut sulit untuk melihat dan mengatur semua konfig di satu tempat. lebih jauh lagi, format seringkali spesifik untuk bahasa pemrograman dan framework tertentu.
+
+
+**Dua belas-faktor app menyimpan konfig dalam *variable Environment*** (sering disingakt *env vars* atau *env*). Evn vars mudah untuk diubah diantara deploy tanpa harus mengubah kode; tidak seperti file konfig, ada sedikit kesempatan untuk dimasukkan tidak sengaja ke kode; tidak seperti file custom konfig, atau mekanisme konfig lain seperti Java System Properties, mereka bersifat agnostik untuk bahasa pemrograman dan sistem operasi.
+
+Aspek lain dari manajemen konfig adalah grouping, seringkali app menjatah sekumpulan konfig ke dalam grup bernama (disebut juga "environments") dinamakan untuk deploy spesifik, seperti `development`, `test`, dan `production` environments dalam Rails. Metode ini tidak meningkat dengan bersih: saat deploy dari app tercipat, nama environment baru dibutuhkan, seperti `staging` or `qa`. saat proyek tumbuh lebih jauh, developer mungkin menambahkan enviroments spesial seperti `joes-staging`, yang berdamapak pada ledakan kombinatorail dari konfig yang membuat pengaturan deploy dari app sangat rapuh.
+
+Di Dua belas-faktor app, env vars adalah kontrol granular, setiap dari itu ortogonal ke env vars lain. Mereka tidak di-grup bersama seperti "environments", namun diatur secara independen untuk setiap deploy. model ini meningkat cepat saat app secara alamiah membesar ke deploy yang lebih banyak dalam daur hidupnya.
+

content/id/dependencies.md

@@ -0,0 +1,12 @@
+## II. Dependencies
+### Secara eksplisit mendeklarasi dan mengisolasi dependencies
+
+Kebanyakan bahasa pemrograman menyediakan suatu sistem paket untuk menyebarkan library pendukung, seperti [CPAN](http://www.cpan.org/) untuk Perl atau [Rubygems](http://rubygems.org/) untuk Ruby. Library diinstall melalui sebuah sistem pemaketan yang dapat diinstall memenuhi-sistem (disebut juga "site packages") atau terbatas ke dalam suatu direktori yang terdapat app (disebut juga sebagai "vendoring" atau "bundling").
+
+**suatu duabelas-faktor ap ptidak pernah bergantung pada paket yang memenuhi-sistem.** app tersebut mendeklarasikan semua dependecies, secara komplit dan pasti, melalui sebuah wujud *deklarasi dependency* . lebih jauh pula, Hal ini menggunakan sebuah kakas *isolasi dependency* selama eksekusi untuk memastikan bahwa tidak terdapat dependency implisit "bocor" dari system sekitar. spesifikasi dependency secara penuh dan eksplisit diaplikasi secara seragam untuk produksi dan pengembangan.
+
+sebagai contoh, [Bundler](https://bundler.io/) untuk Ruby menyediakan format wujud `Gemfile` untuk deklarasi dependency dan `bundel-exec` untuk isolasi dependency. Pada Python terdapat dua kakas terpisah untuk langkah -- [Pip](http://www.pip-installer.org/en/latest/) yang digunakan untuk deklrasai dan [Virtualenv](http://www.virtualenv.org/en/latest/) untuk isolasi. Bahkan C memiliki [Autoconf](http://www.gnu.org/s/autoconf/) untuk deklarasi dependency, dan sambungan statik yang disediakan untuk isolasi dependency. Apapun kakas berantai yang digunakan, deklarasi dependency dan isolasinya harus digunakan bersama -- hanya satu dari keduanya tidak cukup untuk memenuhi keduabelas-faktor.
+
+Salah satu keuntungan dari deklarasi dependency yang eksplisit adalah menyederhanakan setup untuk developers yang baru. developer baru dapat memperoleh codebase app ke dalam mesin pengembangan mereka, dengan hanya membutuhkan runtime bahasa pemrograman dan manajer dependency yang terpasang sebagai prasyarat. Mereka akan mampu untuk menset up semua yang dibutuhkan untuk menjalankan kode app dengan *build command* yang deterministik. sebagai contoh, build command untuk Ruby/Bundler adalah `bundle-install`, sedangkan untuk  Clojure/[Leiningen](https://github.com/technomancy/leiningen#readme) adalah`lein deps`.
+
+Duabelas-faktor app juga tidak bergantung pada eksitensi implisit dari suatu kakas pada system. contohnya tidak menggunakan ImageMagick atau `curl`. walaupun di sistem kebanyakan kakas ini ada, tidak ada garansi bahwa mereka akan selalu ada di semua sistem yang app tersebut akan berjalan di masa depan, atau apakah versi dari sistem di masa depan akan kompatibel dengan app. jika app memerlukan penggunaan kakas sistem, tool itu harus divendorkan ke dalam app.