Pertama, sedikit teori. Apa dah jadi ?
Secara ringkasnya, dokumen ini direka bentuk untuk memudahkan pembangunan aplikasi SaaS, membantu dengan memaklumkan pembangun dan jurutera DevOps tentang masalah dan amalan yang paling kerap dihadapi dalam pembangunan aplikasi moden.
Dokumen itu dicipta oleh pemaju platform Heroku.
Apl Twelve-Factor boleh digunakan pada aplikasi yang ditulis dalam mana-mana bahasa pengaturcaraan dan menggunakan sebarang gabungan perkhidmatan sokongan (pangkalan data, baris gilir mesej, cache, dll.).
Secara ringkas tentang faktor yang menjadi asas metodologi ini:
- Pangkalan kod β Satu pangkalan kod dijejaki dalam kawalan versi β pelbagai penggunaan
- Kebergantungan β Mengisytiharkan dan mengasingkan kebergantungan secara eksplisit
- Konfigurasi β Simpan konfigurasi dalam masa jalan
- Perkhidmatan Penyokong β Pertimbangkan perkhidmatan sokongan sebagai sumber pemalam
- Bina, lepaskan, jalankan β Asingkan dengan ketat peringkat pemasangan dan pelaksanaan
- Proses β Jalankan aplikasi sebagai satu atau lebih proses tanpa kewarganegaraan
- Pengikatan pelabuhan β Perkhidmatan eksport melalui pengikatan pelabuhan
- Paralelisme β Skalakan aplikasi anda menggunakan proses
- Kebolehgunaan β Maksimumkan kebolehpercayaan dengan permulaan pantas dan penutupan bersih
- Pariti pembangunan aplikasi/operasi β Pastikan persekitaran pembangunan, pementasan dan pengeluaran anda sama seperti yang mungkin
- Pembalakan β Lihat log sebagai aliran peristiwa
- Tugas pentadbiran β Melaksanakan tugas pentadbiran/pengurusan menggunakan proses ad hoc
Anda boleh mendapatkan maklumat lanjut tentang 12 faktor daripada sumber berikut:
- - mesti dibaca
- - terjemahan rasmi
- - melihat semula 12 faktor dengan tujuan untuk memperbaikinya.
Apakah itu penempatan Biru-Hijau?
Arahan Biru-Hijau ialah kaedah menghantar aplikasi kepada pengeluaran dengan cara yang pelanggan akhir tidak melihat apa-apa perubahan di pihaknya. Dalam erti kata lain, menggunakan aplikasi dengan sifar downtime.
Skim BG Deploy klasik kelihatan seperti yang ditunjukkan dalam imej di bawah.
- Pada permulaannya terdapat 2 pelayan fizikal dengan kod, aplikasi, projek yang sama, dan terdapat penghala (pengimbang).
- Penghala pada mulanya mengarahkan semua permintaan ke salah satu pelayan (hijau).
- Pada masa ini apabila anda perlu mengeluarkan semula, keseluruhan projek dikemas kini pada pelayan lain (biru), yang tidak sedang memproses sebarang permintaan.
- Selepas kod dihidupkan biru pelayan dikemas kini sepenuhnya, penghala diberi arahan untuk beralih daripadanya hijau pada biru pelayan.
- Kini semua pelanggan melihat hasil kod berjalan dengan biru pelayan.
- Untuk beberapa lama, hijau pelayan berfungsi sebagai salinan sandaran sekiranya tidak berjaya digunakan untuk biru pelayan dan sekiranya berlaku kegagalan dan pepijat, penghala menukar aliran pengguna kembali ke hijau pelayan dengan versi stabil lama, dan kod baharu dihantar untuk semakan dan ujian.
- Dan pada akhir proses, ia dikemas kini dengan cara yang sama hijau pelayan. Dan selepas mengemas kininya, penghala menukar aliran permintaan kembali kepada hijau pelayan.
Semuanya kelihatan sangat baik dan pada pandangan pertama tidak sepatutnya ada masalah dengannya.
Tetapi kerana kita hidup dalam dunia moden, pilihan dengan penukaran fizikal seperti yang ditunjukkan dalam skema klasik tidak sesuai dengan kita. Catat maklumat buat masa ini, kami akan kembali kepadanya kemudian.
Nasihat yang buruk dan baik
Penafian: Contoh di bawah menunjukkan utiliti/metodologi yang saya gunakan, anda boleh menggunakan sebarang alternatif dengan fungsi yang serupa.
Kebanyakan contoh akan dalam satu cara atau yang lain bersilang dengan pembangunan web (ini adalah satu kejutan), dengan PHP dan Docker.
Perenggan di bawah memberikan penerangan praktikal ringkas tentang penggunaan faktor menggunakan contoh khusus; jika anda ingin mendapatkan lebih banyak teori tentang topik ini, ikuti pautan di atas ke sumber asal.
1. Pangkalan Kod
Gunakan FTP dan FileZilla untuk memuat naik fail ke pelayan satu demi satu, jangan simpan kod di mana-mana selain daripada pelayan pengeluaran.
Projek itu harus sentiasa mempunyai asas kod tunggal, iaitu, semua kod datang daripada satu Git repositori. Pelayan (pengeluaran, pementasan, ujian1, ujian2...) menggunakan kod daripada cawangan satu repositori biasa. Dengan cara ini kita mencapai konsistensi kod.
2. Kebergantungan
Muat turun semua perpustakaan dalam folder terus ke akar projek. Buat kemas kini hanya dengan memindahkan kod baharu ke folder dengan versi perpustakaan semasa. Pasang semua utiliti yang diperlukan terus pada pelayan hos di mana 20 lagi perkhidmatan sedang dijalankan.
Projek harus sentiasa mempunyai senarai kebergantungan yang boleh difahami dengan jelas (dengan kebergantungan yang saya maksudkan juga persekitaran). Semua kebergantungan mesti ditakrifkan dengan jelas dan diasingkan.
Mari kita ambil sebagai contoh Karang ΠΈ buruh pelabuhan.
Karang β pengurus pakej yang membolehkan anda memasang perpustakaan dalam PHP. Komposer membenarkan anda untuk menentukan versi secara ketat atau longgar, dan mentakrifkannya secara eksplisit. Terdapat 20 projek berbeza pada pelayan dan setiap satu akan mempunyai senarai peribadi pakej dan perpustakaan yang tidak bergantung kepada yang lain.
buruh pelabuhan β utiliti yang membolehkan anda menentukan dan mengasingkan persekitaran di mana aplikasi akan dijalankan. Sehubungan itu, sama seperti komposer, tetapi dengan lebih teliti, kita boleh menentukan dengan apa aplikasi itu berfungsi. Pilih versi PHP tertentu, pasang hanya pakej yang diperlukan untuk projek itu berfungsi, tanpa menambah apa-apa tambahan. Dan yang paling penting, tanpa mengganggu pakej dan persekitaran mesin hos dan projek lain. Iaitu, semua projek pada pelayan yang dijalankan melalui Docker boleh menggunakan sebarang set pakej dan persekitaran yang sama sekali berbeza.
3. Konfigurasi
Simpan konfigurasi sebagai pemalar terus dalam kod. Pemalar berasingan untuk pelayan ujian, berasingan untuk pengeluaran. Ikat operasi aplikasi bergantung pada persekitaran secara langsung dalam logik perniagaan projek menggunakan if else constructs.
Konfigurasi - ini adalah satu-satunya cara penggunaan projek harus berbeza. Sebaik-baiknya, konfigurasi harus melalui pembolehubah persekitaran (env vars).
Iaitu, walaupun anda menyimpan beberapa fail konfigurasi .config.prod .config.local dan menamakan semula mereka pada masa penggunaan kepada .config (konfigurasi utama dari mana aplikasi membaca data) - ini bukan pendekatan yang betul, kerana dalam kes ini maklumat daripada konfigurasi akan tersedia secara terbuka kepada semua pembangun aplikasi dan data daripada pelayan pengeluaran akan terjejas. Semua konfigurasi mesti disimpan terus dalam sistem penggunaan (CI/CD) dan dijana untuk persekitaran berbeza dengan nilai berbeza yang diperlukan untuk persekitaran tertentu pada masa penggunaan.
4. Perkhidmatan Pihak Ketiga
Terikat dengan persekitaran, gunakan sambungan yang berbeza untuk perkhidmatan yang sama dalam persekitaran tertentu.
Malah, titik ini sangat bertindih dengan titik tentang konfigurasi, kerana tanpa titik ini, data konfigurasi biasa tidak boleh dibuat dan, secara umum, keupayaan untuk mengkonfigurasi akan berkurangan kepada apa-apa.
Semua sambungan kepada perkhidmatan luaran, seperti pelayan baris gilir, pangkalan data, perkhidmatan caching, mestilah sama untuk kedua-dua persekitaran tempatan dan persekitaran pihak ketiga / pengeluaran. Dalam erti kata lain, pada bila-bila masa, dengan menukar rentetan sambungan, saya boleh menggantikan panggilan ke pangkalan #1 dengan pangkalan #2 tanpa mengubah kod aplikasi. Atau, melihat ke hadapan, sebagai contoh, apabila menskala perkhidmatan, anda tidak perlu menentukan sambungan dalam sebarang cara khas untuk pelayan cache tambahan.
5. Bina, lepaskan, laksanakan
Hanya miliki versi akhir kod pada pelayan, tanpa peluang untuk melancarkan keluaran. Tidak perlu mengisi ruang cakera. Sesiapa yang berpendapat bahawa mereka boleh mengeluarkan kod ke dalam pengeluaran dengan ralat adalah pengaturcara yang buruk!
Semua peringkat penggunaan mesti diasingkan antara satu sama lain.
Sempatlah berguling balik. Buat keluaran dengan salinan lama aplikasi (sudah dipasang dan sedia untuk berperang) yang disimpan dalam akses pantas, supaya sekiranya berlaku ralat, anda boleh memulihkan versi lama. Iaitu, dengan syarat terdapat folder siaran dan folder semasa, dan selepas penggunaan dan pemasangan folder berjaya semasa dipautkan dengan pautan simbolik kepada keluaran baharu yang terdapat di dalamnya siaran dengan nama konvensional nombor keluaran.
Di sinilah kami mengingati penggunaan Biru-Hijau, yang membolehkan anda bukan sahaja bertukar antara kod, tetapi juga menukar antara semua sumber dan juga persekitaran dengan keupayaan untuk melancarkan segala-galanya.
6. Proses
Simpan data keadaan aplikasi secara langsung dalam aplikasi itu sendiri. Gunakan sesi dalam RAM aplikasi itu sendiri. Gunakan sebanyak mungkin perkongsian antara perkhidmatan pihak ketiga. Bergantung pada fakta bahawa aplikasi hanya boleh mempunyai satu proses dan tidak membenarkan penskalaan.
Mengenai sesi, simpan data hanya dalam cache yang dikawal oleh perkhidmatan pihak ketiga (memcached, redis), jadi walaupun anda mempunyai 20 proses aplikasi berjalan, mana-mana daripada mereka, setelah mengakses cache, akan dapat terus bekerja dengan klien dalam keadaan yang sama di mana pengguna bekerja dengan aplikasi dalam proses lain. Dengan pendekatan ini, ternyata tidak kira berapa banyak salinan perkhidmatan pihak ketiga yang anda gunakan, semuanya akan berfungsi seperti biasa dan tanpa masalah dengan akses kepada data.
7. Pelabuhan mengikat
Hanya pelayan web harus tahu cara bekerja dengan perkhidmatan pihak ketiga. Atau lebih baik lagi, pasang perkhidmatan pihak ketiga terus di dalam pelayan web. Sebagai contoh, sebagai modul PHP dalam Apache.
Semua perkhidmatan anda mesti boleh diakses antara satu sama lain melalui akses kepada beberapa alamat dan port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000), iaitu, dari nginx saya boleh mengakses kedua-dua php- fpm dan ke postgres, dan dari php-fpm ke postgres dan nginx dan sebenarnya dari setiap perkhidmatan saya boleh mengakses perkhidmatan lain. Dengan cara ini, daya maju sesuatu perkhidmatan tidak terikat dengan daya maju perkhidmatan lain.
8. Paralelisme
Bekerja dengan satu proses, jika tidak beberapa proses tidak akan dapat bergaul antara satu sama lain!
Tinggalkan ruang untuk penskalaan. Docker swarm sangat bagus untuk ini.
Docker Swarm ialah alat untuk mencipta dan mengurus kelompok bekas antara mesin yang berbeza dan sekumpulan bekas pada mesin yang sama.
Menggunakan swarm, saya boleh menentukan berapa banyak sumber yang akan saya peruntukkan untuk setiap proses dan berapa banyak proses perkhidmatan yang sama yang akan saya lancarkan, dan pengimbang dalaman, yang menerima data pada port tertentu, akan secara automatik memproksikannya kepada proses. Oleh itu, melihat bahawa beban pada pelayan telah meningkat, saya boleh menambah lebih banyak proses, dengan itu mengurangkan beban pada proses tertentu.
9. Kebolehgunaan
Jangan gunakan baris gilir untuk bekerja dengan proses dan data. Membunuh satu proses harus menjejaskan keseluruhan aplikasi. Jika satu perkhidmatan turun, semuanya akan turun.
Setiap proses dan perkhidmatan boleh dimatikan pada bila-bila masa dan ini tidak sepatutnya menjejaskan perkhidmatan lain (sudah tentu, ini tidak bermakna perkhidmatan itu tidak akan tersedia untuk perkhidmatan lain, tetapi perkhidmatan lain tidak akan dimatikan selepas ini). Semua proses mesti ditamatkan dengan baik, supaya apabila ia ditamatkan, tiada data akan rosak dan sistem akan berfungsi dengan betul apabila anda menghidupkannya seterusnya. Iaitu, walaupun sekiranya berlaku penamatan kecemasan, data tidak boleh rosak (mekanisme transaksi sesuai di sini, pertanyaan dalam pangkalan data berfungsi hanya dalam kumpulan, dan jika sekurang-kurangnya satu pertanyaan daripada kumpulan gagal atau dilaksanakan dengan ralat, maka tiada pertanyaan lain daripada kumpulan yang akhirnya gagal sebenarnya).
10. Pembangunan aplikasi/pariti operasi
Pengeluaran, pementasan dan versi tempatan aplikasi mestilah berbeza. Dalam pengeluaran kami menggunakan rangka kerja Yii Lite, dan Yii tempatan, supaya ia berfungsi lebih pantas dalam pengeluaran!
Pada hakikatnya, semua penempatan dan kerja dengan kod harus berada dalam persekitaran yang hampir sama (kita tidak bercakap tentang perkakasan fizikal). Selain itu, mana-mana pekerja pembangunan harus dapat menggunakan kod ke pengeluaran jika perlu, dan bukan beberapa jabatan devops yang terlatih khas, yang hanya terima kasih kepada kekuatan khas boleh mengangkat aplikasi ke dalam pengeluaran.
Docker juga membantu kami dengan ini. Jika semua titik sebelumnya diperhatikan, menggunakan docker akan membawa proses penggunaan persekitaran pada pengeluaran dan pada mesin tempatan untuk memasukkan satu atau dua arahan.
11. Log
Kami menulis log ke fail dan pangkalan data! Kami tidak membersihkan fail dan pangkalan data daripada log. Mari kita beli cakera keras dengan 9000 Peta bait dan tidak mengapa.
Semua log harus dianggap sebagai aliran peristiwa. Aplikasi itu sendiri tidak seharusnya terlibat dalam pemprosesan log. Log harus dikeluarkan sama ada untuk stdout atau dihantar melalui protokol seperti udp, supaya bekerja dengan log tidak menimbulkan sebarang masalah untuk aplikasi. graylog bagus untuk ini. Graylog yang menerima semua log melalui udp (protokol ini tidak memerlukan menunggu respons tentang penerimaan paket yang berjaya) tidak mengganggu aplikasi dalam apa jua cara dan hanya berurusan dengan penstrukturan dan pemprosesan log. Logik aplikasi tidak berubah untuk berfungsi dengan pendekatan sedemikian.
12. Tugas pentadbiran
Untuk mengemas kini data, pangkalan data, dsb., gunakan titik akhir yang dibuat secara berasingan dalam API, melaksanakannya 2 kali berturut-turut akan menyebabkan segala-galanya diduplikasi. Tetapi anda tidak bodoh, anda tidak akan mengklik dua kali, dan kami tidak memerlukan penghijrahan.
Semua tugas pentadbiran harus dilakukan dalam persekitaran yang sama seperti semua kod, pada tahap keluaran. Iaitu, jika kita perlu menukar struktur pangkalan data, maka kita tidak akan melakukannya secara manual dengan menukar nama lajur dan menambah yang baharu melalui beberapa alat pengurusan pangkalan data visual. Untuk perkara sedemikian, kami mencipta skrip berasingan - migrasi, yang dilaksanakan di mana-mana dan dalam semua persekitaran dengan cara yang sama dengan hasil yang sama dan boleh difahami. Untuk semua tugas lain, seperti mengisi projek dengan data, metodologi yang serupa harus digunakan.
Contoh pelaksanaan dalam PHP, Laravel, Laradock, Docker-Compose
PS Semua contoh dibuat pada MacOS. Kebanyakannya juga sesuai untuk Linux. Pengguna Windows, maafkan saya, tetapi saya sudah lama tidak bekerja dengan Windows.
Mari bayangkan situasi di mana kita tidak mempunyai sebarang versi PHP yang dipasang pada PC kita dan tiada langsung.
Pasang versi terkini docker dan docker-compose. (ini boleh didapati di Internet)
docker -v &&
docker-compose -v
1. Letakkan
git clone https://github.com/Laradock/laradock.git &&
ls
Mengenai Laradock, saya akan mengatakan bahawa ia adalah perkara yang sangat keren, yang mengandungi banyak bekas dan perkara tambahan. Tetapi saya tidak akan mengesyorkan menggunakan Laradock seperti itu tanpa pengubahsuaian dalam pengeluaran kerana redundansinya. Adalah lebih baik untuk mencipta bekas anda sendiri berdasarkan contoh dalam Laradock, ini akan menjadi lebih dioptimumkan, kerana tiada siapa yang memerlukan semua yang ada pada masa yang sama.
2. Konfigurasikan Laradock untuk menjalankan aplikasi kami.
cd laradock &&
cp env-example .env
2.1. Buka direktori habr (folder induk di mana laradock diklon) dalam sesetengah editor. (Dalam kes PHPStorm saya)
Pada peringkat ini kami hanya memberi nama projek.
2.2. Lancarkan imej ruang kerja. (Dalam kes anda, imej akan mengambil sedikit masa untuk dibina)
Ruang kerja ialah imej yang disediakan khas untuk bekerja dengan rangka kerja bagi pihak pembangun.
Kami masuk ke dalam bekas menggunakan
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Memasang Laravel
composer create-project --prefer-dist laravel/laravel application
2.4. Selepas pemasangan, kami menyemak sama ada direktori dengan projek telah dibuat dan bunuh mengarang.
ls
exit
docker-compose down
2.5. Mari kembali ke PHPStorm dan tetapkan laluan yang betul kepada aplikasi laravel kami dalam fail .env.
3. Tambahkan semua kod pada Git.
Untuk melakukan ini, kami akan membuat repositori pada Github (atau di mana-mana sahaja). Mari pergi ke direktori habr di terminal dan laksanakan kod berikut.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # Π·Π΄Π΅ΡΡ Π±ΡΠ΄Π΅Ρ ΡΡΡΠ»ΠΊΠ° Π½Π° Π²Π°Ρ ΡΠ΅ΠΏΠΎ
git push -u origin master
git status
Mari semak sama ada semuanya teratur.
Untuk kemudahan, saya syorkan menggunakan beberapa antara muka visual untuk Git, dalam kes saya, ia adalah . (ini adalah pautan rujukan)
4. Jom lancarkan!
Sebelum memulakan, pastikan tiada apa-apa yang tergantung pada port 80 dan 443.
docker-compose up -d nginx php-fpm
Oleh itu, projek kami terdiri daripada 3 perkhidmatan berasingan:
- nginx - pelayan web
- php-fpm - php untuk menerima permintaan daripada pelayan web
- ruang kerja - php untuk pembangun
Pada masa ini, kami telah mencapai bahawa kami telah mencipta aplikasi yang memenuhi 4 mata daripada 12, iaitu:
1. Pangkalan kod β semua kod berada dalam satu repositori (nota kecil: mungkin betul untuk menambah docker di dalam projek laravel, tetapi ini tidak penting).
2. Kebergantungan β Semua kebergantungan kami ditulis secara eksplisit dalam application/composer.json dan dalam setiap Dockerfile setiap bekas.
3. Perkhidmatan Penyokong β Setiap perkhidmatan (php-fom, nignx, ruang kerja) menjalani kehidupannya sendiri dan disambungkan dari luar dan apabila bekerja dengan satu perkhidmatan, yang lain tidak akan terjejas.
4. Proses β setiap perkhidmatan adalah satu proses. Setiap perkhidmatan tidak mengekalkan keadaan dalaman.
5. Pengikatan pelabuhan
docker ps
Seperti yang kita dapat lihat, setiap perkhidmatan berjalan pada portnya sendiri dan boleh diakses oleh semua perkhidmatan lain.
6. Paralelisme
Docker membolehkan kami menghasilkan berbilang proses perkhidmatan yang sama dengan pengimbangan beban automatik di antara mereka.
Mari kita hentikan bekas-bekas itu dan jalankan mereka melalui bendera --skala
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Seperti yang kita dapat lihat, salinan telah dibuat bagi bekas php-fpm. Kami tidak perlu mengubah apa-apa dalam bekerja dengan bekas ini. Kami juga terus mengaksesnya pada port 9000, dan Docker mengawal beban antara bekas untuk kami.
7. Kebolehgunaan - setiap bekas boleh dibunuh tanpa membahayakan yang lain. Menghentikan atau memulakan semula bekas tidak akan menjejaskan pengendalian aplikasi semasa pelancaran berikutnya. Setiap bekas juga boleh diangkat pada bila-bila masa.
8. Pariti pembangunan aplikasi/operasi - semua persekitaran kita adalah sama. Dengan menjalankan sistem pada pelayan dalam pengeluaran, anda tidak perlu mengubah apa-apa dalam arahan anda. Semuanya akan berdasarkan Docker dengan cara yang sama.
9. Pembalakan β semua log dalam bekas ini pergi ke strim dan boleh dilihat dalam konsol Docker. (dalam kes ini, sebenarnya, dengan bekas buatan sendiri yang lain, ini mungkin tidak berlaku jika anda tidak menjaganya)
docker-compose logs -f
Tetapi terdapat tangkapan bahawa nilai Lalai dalam PHP dan Nginx juga menulis log ke fail. Untuk memenuhi 12 faktor tersebut, adalah perlu putuskan sambungan menulis log ke fail dalam konfigurasi setiap bekas secara berasingan.
Docker juga menyediakan keupayaan untuk menghantar log bukan sahaja ke stdout, tetapi juga kepada perkara seperti greylog, yang saya nyatakan di atas. Dan di dalam greylog, kami boleh mengendalikan log sesuka hati dan aplikasi kami tidak akan menyedarinya dalam apa jua cara.
10. Tugas pentadbiran β semua tugas pentadbiran diselesaikan oleh laravel terima kasih kepada alat tukang betul-betul seperti yang dikehendaki oleh pencipta aplikasi 12 faktor.
Sebagai contoh, saya akan menunjukkan bagaimana beberapa arahan dilaksanakan.
Kami masuk ke dalam bekas.
docker-compose exec workspace bash
php artisan list
Sekarang kita boleh menggunakan sebarang arahan. (sila ambil perhatian bahawa kami tidak mengkonfigurasi pangkalan data dan cache, jadi separuh daripada arahan tidak akan dilaksanakan dengan betul, kerana ia direka untuk berfungsi dengan cache dan pangkalan data).
11. Konfigurasi dan 12. Bina, lepaskan, jalankan
Saya ingin mendedikasikan bahagian ini kepada Penggunaan Biru-Hijau, tetapi ternyata ia terlalu luas untuk artikel ini. Saya akan menulis artikel berasingan mengenai perkara ini.
Secara ringkasnya, konsep ini berdasarkan sistem CI/CD seperti Jenkins ΠΈ Gitlab CI. Dalam kedua-duanya, anda boleh menetapkan pembolehubah persekitaran yang dikaitkan dengan persekitaran tertentu. Sehubungan itu, dalam situasi ini, titik c akan dipenuhi Konfigurasi.
Dan perkara tentang Bina, lepaskan, jalankan diselesaikan oleh fungsi terbina dalam dengan nama Paip.
Paip membolehkan anda membahagikan proses penempatan kepada banyak peringkat, menyerlahkan peringkat pemasangan, pelepasan dan pelaksanaan. Juga dalam Pipeline, anda boleh membuat sandaran, dan sememangnya apa sahaja. Ini adalah alat dengan potensi tanpa had.
Kod permohonan berada di .
Jangan lupa untuk memulakan submodul apabila mengklon repositori ini.
PS: Semua pendekatan ini boleh digunakan dengan mana-mana utiliti dan bahasa pengaturcaraan lain. Perkara utama ialah intipati tidak berbeza.
Sumber: www.habr.com