Croatian translation

content/hr/admin-processes.md

@@ -0,0 +1,14 @@
+## XII. Administrativni procesi
+### Pokrenite administrativne/upravljačke zadatke kao jednokratne procese
+
+[Formacija procesa](./concurrency) je niz procesa koji se koriste za obavljanje redovnog poslovanja aplikacije (kao što je rukovanje web zahtjevima) dok se ona izvodi. Osim toga, razvijatelji će često htjeti obaviti jednokratne administrativne zadatke ili zadatke održavanja za aplikaciju, kao što su:
+
+* Pokretanje migracija baze podataka (npr. `manage.py migrate` u Djangu, `rake db:migrate` u Railsu).
+* Pokretanje konzole (također poznata kao ljuska [REPL](https://en.wikipedia.org/wiki/Read-eval-print_loop)) za pokretanje proizvoljnog kôda ili pregled modela aplikacije u odnosu na aktivnu bazu podataka. Većina jezika pruža REPL pokretanjem tumača bez ikakvih argumenata (npr. `python` ili `perl`) ili u nekim slučajevima imaju zasebnu naredbu (npr. `irb` za Ruby, `rails console` za Rails).
+* Pokretanje jednokratnih skripti predanih u repozitorij aplikacije (npr. `php scripts/fix_bad_records.php`).
+
+Jednokratni administrativni procesi trebali bi se izvoditi u identičnom okruženju kao i redoviti [dugotrajni procesi](./processes) aplikacije. Pokreću se u odnosu na [izdanje](./build-release-run), koristeći istu [bazu izvornog kôda](./codebase) i [konfiguraciju](./config) kao i bilo koji proces koji se pokreće u odnosu na to izdanje. Administrativni kôd mora biti isporučen s kôdom aplikacije kako bi se izbjegli problemi sa sinkronizacijom.
+
+Iste tehnike [izolacije zavisnosti](./dependencies) trebale bi se koristiti na svim vrstama procesa. Na primjer, ako Ruby web proces koristi naredbu `bundle exec thin start`, tada bi migracija baze podataka trebala koristiti `bundle exec rake db:migrate`. Isto tako, Python program koji koristi Virtualenv trebao bi koristiti isporučeni `bin/python` za pokretanje i web poslužitelja Tornado i svih `manage.py`-evih administrativnih procesa.
+
+Metodologija dvanaest faktora snažno daje prednost jezicima koji pružaju ljusku REPL od početka korištenja i koji olakšavaju pokretanje jednokratnih skripti. U lokalnoj implementaciji, razvijatelji pozivaju jednokratne administrativne procese izravnom naredbom ljuske unutar direktorija za naplatu aplikacije. U produkcijskoj implementaciji, razvijatelji mogu koristiti ssh ili drugi mehanizam za daljinsko izvršavanje naredbi kojeg nudi izvršna okolina te implementacije za pokretanje takvog procesa.

content/hr/background.md

@@ -0,0 +1,8 @@
+Pozadina
+========
+
+Suradnici u izradi ovog dokumenta bili su izravno uključeni u razvoj i implementaciju stotina aplikacija te su neizravno svjedočili razvoju, radu i skaliranju stotina tisuća aplikacija putem našeg rada na platformi [Heroku](https://www.heroku.com/).
+
+Ovaj dokument sintetizira sva naša iskustva i zapažanja o širokom spektru aplikacija softvera kao usluge u divljini (u stvarnom svijetu, op. prev.). To je triangulacija o idealnim praksama za razvoj aplikacija, obraćajući posebnu pozornost na dinamiku organskog rasta aplikacije tijekom vremena, dinamiku suradnje između razvijatelja koji rade na bazi kôda aplikacije i [izbjegavanju troškova erozije softvera](https://blog.heroku.com/the_new_heroku_4_erosion_resistance_explicit_contracts).
+
+Naša motivacija je podići svijest o nekim sustavnim problemima koje smo vidjeli u modernom razvoju aplikacija, pružiti zajednički rječnik za raspravu o tim problemima i ponuditi skup širokih konceptualnih rješenja za te probleme s pratećom terminologijom. Format je inspiriran knjigama Martina Fowlera *[Uzorci arhitekture poslovne aplikacije](https://books.google.com/books?id=FyWZt5DdvFkC)* i *[Refactoring](https://books.google.com/books?id=1MsETFPD3I0C)*.

content/hr/backing-services.md

@@ -0,0 +1,14 @@
+## IV. Potporne usluge
+### Tretirajte potporne usluge kao priložene resurse
+
+*Potporna usluga* je svaka usluga koju aplikacija koristi putem mreže kao dio svog normalnog rada. Primjeri uključuju spremišta podataka (kao što je [MariaDB](https://mariadb.org/) ili [CouchDB](https://couchdb.apache.org/)), sustave za slanje poruka/upravljanje redovima čekanja (kao što je [RabbitMQ](https://www.rabbitmq.com/) ili [Beanstalkd](https://beanstalkd.github.io/)), SMTP usluge za odlaznu e-poštu (kao što je [Postfix](https://www.postfix.org/)) i sustavi za predmemoriju (kao što je [Memcached](https://memcached.org/)).
+
+Potpornim uslugama poput baze podataka tradicionalno upravljaju isti administratori sustava koji implementiraju aplikaciju u izvršnom okruženju. Osim ovih usluga kojima se upravlja lokalno, aplikacija također može imati usluge koje pružaju i kojima upravljaju treće strane. Primjeri uključuju SMTP usluge (kao što je [Postmark](https://postmarkapp.com/)), usluge prikupljanja metrike (kao što je [New Relic](https://newrelic.com/) ili [Loggly](https://www.loggly.com/)), usluge pohrane binarne imovine (kao što je [Amazon S3](https://aws.amazon.com/s3/)), pa čak i korisničke usluge dostupne putem API-ja (kao što je [Twitter](https://developer.twitter.com/), [Google karte](https://developers.google.com/maps/) ili [Last.fm](https://www.last.fm/api)).
+
+**Kôd za dvanestofaktorsku aplikaciju ne pravi razliku između lokalnih usluga i usluga treće strane.** Aplikaciji su obje vrste priloženi resursi, kojima se pristupa putem URL-a ili drugog lokatora/vjerodajnica pohranjenih u [konfiguraciji](./config). [Implementacija](./codebase) dvanaestofaktorske aplikacije trebala bi moći zamijeniti lokalnu MariaDB bazu podataka onom kojom upravlja treća strana (kao što je [Amazon RDS](https://aws.amazon.com/rds/)) bez ikakvih promjena kôda aplikacije. Isto tako, lokalni SMTP poslužitelj mogao bi se zamijeniti SMTP uslugom treće strane (kao što je Postmark) bez promjene kôda. U oba slučaja potrebno je promijeniti samo dršku resursa u konfiguraciji.
+
+Svaka posebna potporna usluga je *resurs*. Na primjer, MariaDB baza podataka je resurs; dvije MariaDB baze podataka (koriste se za usitnjavanje na aplikacijskom sloju) karakteriziraju se kao dva različita resursa. Dvanaestofaktorska aplikacija tretira te baze podataka kao *priložene resurse*, što ukazuje na njihovu labavu povezanost s implementacijom na koju su pripojene.
+
+![Produkcijska implementacija povezana s četiri potporne usluge.](/images/attached-resources.png)
+
+Resursi se mogu po volji priključiti i odvojiti od implementacija. Na primjer, ako se baza podataka aplikacije loše ponaša zbog hardverskog problema, administrator aplikacije može pokrenuti novi poslužitelj baze podataka vraćen iz nedavne sigurnosne kopije. Trenutna produkcijska baza podataka mogla bi se odvojiti, a nova priključiti -- sve bez ikakvih promjena kôda.

content/hr/build-release-run.md

@@ -0,0 +1,18 @@
+## V. Izgradnja, izdavanje, pokretanje
+### Strogo razdvojite stadije izgradnje i pokretanja
+
+[Baza izvornog kôda](./codebase) pretvara se u (nerazvojnu) implementaciju kroz tri stadija:
+
+* *Stadiij izgradnje* je transformacija koja pretvara repo kôda u izvršni paket poznat kao *izgradnja*. Koristeći verziju kôda na commitu navedenom u procesu implementacije, stadij izgradnje dohvaća od dobavljača [zavisnosti](./dependencies) i stvara binarne datoteke i imovinu.
+* *Stadij izdavanja* uzima izgradnju proizvedenu stadijem izgradnje i spaja je s trenutnom [konfiguracijom](./config) implementacije. Rezultirajuće *izdanje* sadrži i izgradnju i konfiguraciju te je spremno za trenutno izvršavanje u izvršnom okruženju.
+* *Stadij pokretanja* (također poznata kao "runtime") pokreće aplikaciju u izvršnom okruženju, pokretanjem nekog skupa [procesa](./processes) aplikacije prema odabranom izdanju.
+
+![Kôd postaje izgradnja koja se kombinira s konfiguracijom za stvaranje izdanja.](/images/release.png)
+
+**Dvanaestofaktorska aplikacija koristi strogo razdvajanje između stadija izgradnje, izdavanja i pokretanja.** Na primjer, nemoguće je unijeti promjene u kôd tijekom izvođenja jer ne postoji način da se te promjene prenesu natrag u stadij izgradnje.
+
+Alati za implementaciju obično nude alate za upravljanje izdanjima, posebice mogućnost vraćanja na prethodno izdanje. Na primjer, alat za implementaciju [Capistrano](https://capistranorb.com/) pohranjuje izdanja u poddirektorij pod nazivom `releases`, gdje je trenutno izdanje simbolička poveznica na trenutni direktorij izdanja. Njegova naredba `rollback` olakšava brzi povratak na prethodno izdanje.
+
+Svako izdanje uvijek treba imati jedinstveni identifikator izdanja, kao što je vremenska oznaka izdanja (kao što je `2011-04-06-20:32:17`) ili rastući broj (kao što je `v100`). Skup izdanja je namijenjen samo za dodavanje i izdanje se ne može mijenjati nakon što je stvoreno. Svaka promjena mora stvoriti novo izdanje.
+
+Izgradnje pokreću razvijatelji aplikacije svaki put kad se implementira novi kôd. Za razliku od toga, pokretanje može se dogoditi automatski tijekom izvršavanja u slučajevima kao što je ponovno pokretanje poslužitelja ili srušeni proces kojeg ponovno pokreće upravitelj procesa. Stoga bi se stadij izvršavanja trebao zadržati na što manje pokretnih dijelova, budući da problemi koji sprječavaju pokretanje aplikacije mogu uzrokovati da se pokvari usred noći kada nema razvijatelja. Stadij izgradnje može biti složeniji, budući da su pogreške uvijek u prvom planu za razvijatelja koji pokreće implementaciju.

content/hr/codebase.md

@@ -0,0 +1,17 @@
+## I. Baza izvornog kôda
+### Jedna baza izvornog kôda praćena u upravljanju revizijama, mnogo implementacija
+
+Dvanaestofaktorska aplikacija uvijek se prati u sustavu upravljanja verzija, kao što je [Git](https://git-scm.com/), [Mercurial](https://www.mercurial-scm.org/), ili [Subversion](https://subversion.apache.org/). Kopija baze podataka za praćenje revizija poznata je kao *spremište kôda*, često skraćeno na *repo kôda* ili samo *repo*.
+
+*Baza izvornog kôda* je bilo koji pojedinačni repo (u centraliziranom sustavu upravljanja revizija kao što je Subversion), ili bilo koji skup repoa koji dijele korijenski commit (u decentraliziranom sustavu upravljanja revizija kao što je Git).
+
+![Jedna baza izvornog kôda preslikava se na mnoge implementacije.](/images/codebase-deploys.png)
+
+Uvijek postoji korelacija jedan na jedan između baze izvornog kôda i aplikacije:
+
+* Ako postoji više baza izvornog kôda, to nije aplikacija -- to je distribuirani sustav. Svaka komponenta u distribuiranom sustavu je aplikacija i svaka se pojedinačno može uskladiti s metodologijom dvanaest faktora.
+* Više aplikacija koje dijele isti kôd predstavlja kršenje metodologije dvanaest faktora. Rješenje je ovdje ugraditi zajednički kôd u knjižnice koje se mogu uključiti putem [upravitelja zavisnosti](./dependencies).
+
+Postoji samo jedna baza izvornog kôda po aplikaciji, ali bit će mnogo implementacija aplikacije. *Implementacija* je pokrenuta instanca aplikacije. Ona je tipično produkcijsko sjedište i jedno ili više probnih sjedišta. Osim toga, svaki razvijatelj ima kopiju aplikacije koja se izvodi u svom lokalnom razvojnom okruženju, a svaka takva se također karakterizira kao implementacija.
+
+Baza izvornog kôda je ista za sve implementacije, iako različite verzije mogu biti aktivne u svakoj implementaciji. Na primjer, razvijatelj ima neke commitove koje još nisu implementirani u uprizorenje; probno sjedište ima neke commitove koji još nisu implemetnirani u produkciju. Ali svi dijele istu bazu izvornog kôda, što ih čini prepoznatljivim kao različite implementacije iste aplikacije.

content/hr/concurrency.md

@@ -0,0 +1,14 @@
+## VIII. Konkurentnost
+### Skalirajte prema van putem modela procesa
+
+Svaki računalni program, jednom pokrenut, predstavljan je od strane jednog ili više procesa. Web aplikacije su imale različite oblike izvršenja procesa. Na primjer, PHP procesi se pokreću kao podređeni procesi Apachea, pokrenuti na zahtjev prema potrebi volumena zahtjeva. Java procesi imaju suprotan pristup, s JVM-om koji pruža jedan masivni uberproces koji rezervira veliki blok sustavskih resursa (CPU i memorija) pri pokretanju, s konkurentnošću kojom se interno upravlja putem niti. U oba slučaja, pokrenuti proces(i) samo su minimalno vidljivi razvijateljima aplikacije.
+
+![Skala se izražava kao broj pokrenutih procesa, raznolikost radnog opterećenja se izražava kao vrste procesa.](/images/process-types.png)
+
+**U dvanaestofaktorskoj aplikaciji procesi su "građani prve klase".** Procesi u dvanaestofaktorskoj aplikaciji uzimaju snažne znakove iz [Unixovog modela procesa za pokretanje uslužnih daemona](https://adam.herokuapp.com/past/2011/5/9/applying_the_unix_process_model_to_web_apps/). Koristeći ovaj model, razvijatelj može projektirati svoju aplikaciju za rukovanje različitim radnim opterećenjima dodjeljivanjem svake vrste posla *vrsti procesa*. Na primjer, HTTP zahtjevima može rukovati web proces, a dugotrajnim pozadinskim zadacima upravlja proces radnika.
+
+To ne isključuje pojedinačne procese iz rukovanja vlastitim internim multipleksiranjem, putem niti unutar VM-a u vremenu izvođenja, ili asinkronog/događajnog modela koji se nalazi u alatima kao što su [EventMachine](https://github.com/eventmachine/eventmachine), [Twisted](https://twistedmatrix.com/trac/) ili [Node.js](https://nodejs.org/). No, pojedinačni VM može narasti samo tako velik (u uspravnoj skali), tako da aplikacija također mora moći obuhvatiti više procesa koji se pokreću na više fizičkih strojeva.
+
+Procesni model uistinu zablista kada dođe vrijeme za skaliranje prema van. [Ne-dijeli-ništa, horizontalno particiona priroda procesa dvanaestofaktorske aplikacije](./processes) znači da je dodavanje više konkurentnosti jednostavna i pouzdana operacija. Niz tipova procesa i broj procesa svake vrste poznat je kao *formacija procesa*.
+
+Procesi dvanaestofaktorske aplikacije [nikada se ne bi trebali daemonizirati](https://dustin.sallings.org/2010/02/28/running-processes.html) ili pisati PID datoteke. Umjesto toga, oslanjaju se na upravitelja procesa operacijskog sustava (kao što je [systemd](https://www.freedesktop.org/wiki/Software/systemd/), upravitelj distribuiranih procesa na platformi u oblaku ili alat kao što je [Foreman](http://blog.daviddollar.org/2011/05/06/introducing-foreman.html) u razvoju) za upravljanje [izlaznim tokovima](./logs), odgovaranje na srušene procese i rukovanje ponovnim pokretanjima koja je započeo korisnik i isključivanjem.

content/hr/config.md

@@ -0,0 +1,22 @@
+## III. Konfiguracija
+### Pohranite konfiguraciju u okruženje
+
+*Konfiguracija* aplikacije je sve ono što će vjerojatno varirati između [implementacija](./codebase) (uprizorenje, produkcija, razvojna okruženja itd.). Ovo uključuje:
+
+* Dršku resursa za bazu podataka, Memcached i druge [potporne usluge](./backing-services)
+* Vjerodajnice za vanjske usluge kao što su Amazon S3 ili Twitter
+* Vrijednosti specifične za pojedinu implementaciju kao što je kanonsko ime domaćina te implementacije
+
+Aplikacije ponekad spremaju konfiguraciju kao konstante u kôdu. Ovo je kršenje metodologije dvanaest faktora, koja zahtijeva **strogo odvajanje konfiguracije od kôda**. Konfiguracija se značajno razlikuje od implementacije do implementacije, kôd ne.
+
+Lakmus test za to da li aplikacija ima sve konfiguracije ispravno izvučene iz kôda je može li se baza izvornog kôda u bilo kojem trenutku učiniti otvorenim kôdom, bez ugrožavanja vjerodajnica.
+
+Imajte na umu da ova definicija "konfiguracije" **ne** uključuje internu konfiguraciju aplikacije, kao što je `config/routes.rb` u Railsu, ili kako su [moduli kôda povezani](https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-introduction) u [Springu](https://spring.io/). Ova vrsta konfiguracije se ne razlikuje između implementacije, pa je najbolje da bude izvedena u kôdu.
+
+Drugi pristup konfiguraciji je korištenje konfiguracijskih datoteka koje nisu upisane u upravljanju revizijama, kao što je `config/database.yml` u Railsu. Ovo je veliko poboljšanje u odnosu na korištenje konstanti koje se upisuju u repo kôda, ali još uvijek ima slabosti: lako je greškom upisati konfiguracijsku datoteku u repo; postoji tendencija da konfiguracijske datoteke budu razbacane na različitim mjestima i u različitim formatima, što otežava pregled i upravljanje svim konfiguracijama na jednom mjestu. Nadalje, ovi formati obično su specifični za jezik ili okvir.
+
+**Dvanaestofaktorska aplikacija pohranjuje konfiguraciju u *varijable okruženja*** (često skraćeno na *env vars* ili *env*). Env vars je lako mijenjati između implementacija bez promjene kôda; za razliku od konfiguracijskih datoteka, male su šanse da budu slučajno upisane u repo kôda; i za razliku od prilagođenih konfiguracijskih datoteka ili drugih konfiguracijskih mehanizama kao što su Java System Properties, one su standard koji ne ovisi o jeziku i OS-u.
+
+Drugi aspekt upravljanja konfiguracijom je grupiranje. Ponekad aplikacije gomilaju konfiguriraciju u imenovane grupe (koje se često nazivaju "okruženja") nazvane prema određenim implementacijama, kao što su okruženja `development`, `test` i `production` u Railsu. Ova metoda ne skalira čisto: kako se stvara više implementacija aplikacije, potrebni su novi nazivi okruženja, kao što su `staging` ili `qa`. Kako projekt dalje raste, razvijatelji mogu dodati svoja posebna okruženja kao što je `joes-staging`, što rezultira kombinatornom eksplozijom konfiguracije, što upravljanje implementacijama aplikacije čini vrlo krhkim.
+
+U dvanaestofaktorskoj aplikaciji, env vars su granularne kontrole, svaka potpuno ortogonalna na druge env vars. Nikada se ne grupiraju zajedno kao "okruženja", već se njima samostalno upravlja za svaku implementaciju. Ovo je model koji glatko skaliram prema gore jer se aplikacija prirodno širi na više implementacija tijekom svog životnog vijeka.