Pernahkah Anda mempelajari perintah Git tetapi ingin membayangkan cara kerja integrasi berkelanjutan (CI) di dunia nyata? Atau mungkin Anda ingin mengoptimalkan aktivitas sehari-hari? Kursus ini akan memberi Anda keterampilan praktis dalam integrasi berkelanjutan menggunakan repositori GitHub. Kursus ini tidak dimaksudkan sebagai panduan yang cukup Anda klik; sebaliknya, Anda akan melakukan tindakan yang sama seperti yang sebenarnya dilakukan orang di tempat kerja, dengan cara yang sama seperti yang mereka lakukan. Saya akan menjelaskan teorinya saat Anda melalui langkah-langkah yang terlibat.

Apa yang kita lakukan?

Seiring kemajuan kami, kami secara bertahap akan membuat daftar langkah-langkah CI yang umum, yang merupakan cara terbaik untuk mengingat daftar ini. Dengan kata lain, kami akan membuat daftar tindakan yang dilakukan pengembang saat melakukan integrasi berkelanjutan, melakukan integrasi berkelanjutan. Kami juga akan menggunakan serangkaian pengujian sederhana untuk mendekatkan proses CI kami dengan proses sebenarnya.

GIF ini secara skematis menunjukkan penerapan di repositori Anda saat Anda melanjutkan kursus. Seperti yang Anda lihat, tidak ada yang rumit di sini dan hanya yang paling penting.

Anda akan melalui skenario CI standar berikut:

• Kerjakan sebuah fitur;
• Penerapan pengujian otomatis untuk memastikan kualitas;
• Pelaksanaan tugas prioritas;
• Penyelesaian konflik pada saat penggabungan cabang (merge konflik);
• Terjadi kesalahan di lingkungan produksi.

Apa yang akan Anda pelajari?

Anda akan dapat menjawab pertanyaan-pertanyaan berikut:

• Apa itu integrasi berkelanjutan (CI)?
• Jenis pengujian otomatis apa yang digunakan di CI, dan sebagai respons terhadap tindakan apa yang dipicunya?
• Apa itu pull request dan kapan dibutuhkan?
• Apa itu Test Driven Development (TDD) dan apa kaitannya dengan CI?
• Haruskah saya menggabungkan atau mengubah perubahan?
• Kembalikan atau perbaiki di versi berikutnya?

Awalnya saya menerjemahkan hal-hal seperti “permintaan tarik” di mana-mana, tetapi sebagai hasilnya saya memutuskan untuk mengembalikan frasa dalam bahasa Inggris di beberapa tempat untuk mengurangi tingkat kegilaan dalam teks. Kadang-kadang saya menggunakan "programmer surzhik" seperti kata kerja "commit" yang indah di mana orang benar-benar menggunakannya di tempat kerja.

Apa itu integrasi berkelanjutan?

Integrasi Berkelanjutan, atau CI, adalah praktik teknis di mana setiap anggota tim mengintegrasikan kode mereka ke dalam repositori umum setidaknya sekali sehari, dan kode yang dihasilkan setidaknya harus dibuat tanpa kesalahan.

Ada perbedaan pendapat tentang istilah ini

Titik perdebatannya adalah frekuensi integrasi. Beberapa orang berpendapat bahwa menggabungkan kode hanya sekali sehari tidak cukup untuk benar-benar berintegrasi secara terus menerus. Contoh yang diberikan adalah sebuah tim di mana setiap orang mengambil kode baru di pagi hari dan mengintegrasikannya sekali di malam hari. Meskipun hal ini merupakan keberatan yang masuk akal, secara umum diyakini bahwa definisi sekali sehari cukup praktis, spesifik, dan cocok untuk tim dengan ukuran berbeda.

Keberatan lainnya adalah bahwa C++ bukan lagi satu-satunya bahasa yang digunakan dalam pengembangan, dan hanya membutuhkan perakitan bebas kesalahan sebagai cara validasi saja sudah lemah. Beberapa rangkaian pengujian (misalnya, pengujian unit yang dijalankan secara lokal) juga harus berhasil diselesaikan. Saat ini, komunitas mulai menjadikan hal ini sebagai persyaratan, dan di masa depan, "build + unit test" mungkin akan menjadi praktik umum, jika hal ini belum dilakukan.

Integrasi Berkelanjutan berbeda dari pengiriman terus menerus (Pengiriman Berkelanjutan, CD) karena tidak memerlukan kandidat rilis setelah setiap siklus integrasi.

Daftar langkah-langkah yang akan kami gunakan sepanjang kursus

1. Tarik kode terbaru. Buat cabang dari master. Mulai bekerja.
2. Buat komitmen di cabang baru Anda. Bangun dan uji secara lokal. Lulus? Lanjutkan ke langkah berikutnya. Gagal? Perbaiki kesalahan atau pengujian dan coba lagi.
3. Dorong ke repositori jarak jauh atau cabang jarak jauh Anda.
4. Buat permintaan tarik. Diskusikan perubahannya, tambahkan lebih banyak komitmen saat diskusi berlanjut. Lakukan pengujian pada cabang fitur.
5. Gabungkan/rebase komit dari master. Lakukan pengujian pada hasil penggabungan.
6. Terapkan dari cabang fitur ke produksi.
7. Jika semuanya baik-baik saja dalam produksi selama jangka waktu tertentu, gabungkan perubahan ke master.

️ Persiapan

Pastikan Anda memiliki perangkat lunak yang tepat

Untuk mengikuti kursus ini, Anda memerlukannya Node.js и klien Git.

Anda dapat menggunakan klien Git apa pun, tetapi saya hanya akan memberikan perintah untuk baris perintah.

Pastikan Anda menginstal klien Git yang mendukung baris perintah

Jika Anda belum memiliki klien Git yang mendukung baris perintah, Anda dapat menemukan petunjuk instalasi di sini.

Siapkan repositori

Anda perlu membuat salinan pribadi (garpu) repositori templat dengan kode untuk kursus di GitHub. Mari kita sepakat untuk menyebut salinan pribadi ini gudang kursus.

Selesai? Jika Anda belum mengubah pengaturan default, kemungkinan besar repositori kursus Anda akan dipanggil continuous-integration-team-scenarios-students, itu terletak di akun GitHub Anda dan URL-nya terlihat seperti ini

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Saya hanya akan menelepon alamat ini <URL репозитория>.

Tanda kurung sudut seperti <тут> berarti Anda harus mengganti ekspresi tersebut dengan nilai yang sesuai.

Pastikan bahwa Tindakan GitHub disertakan untuk repositori kursus ini. Jika tindakan tersebut tidak diaktifkan, harap aktifkan dengan mengeklik tombol besar di tengah halaman, yang dapat Anda buka dengan mengeklik Tindakan di antarmuka GitHub.

Anda tidak akan dapat menyelesaikan kursus dengan mengikuti instruksi saya jika Tindakan GitHub tidak diaktifkan.

Anda selalu dapat menggunakan kemampuan GitHub untuk merender Markdown untuk melihat status terkini dari daftar yang kami buat di sini

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

Tentang jawabannya

Meskipun cara terbaik untuk menyelesaikan kursus ini adalah dengan melakukannya sendiri, Anda mungkin mengalami beberapa kesulitan.

Jika Anda merasa tidak mengerti apa yang harus dilakukan dan tidak bisa melanjutkan, Anda bisa melihat ke dalam thread solution, yang ada di repositori awal Anda.
Tolong jangan bergabung solution в master selama kursus. Anda dapat menggunakan cabang ini untuk mencari tahu apa yang harus dilakukan, atau untuk membandingkan kode Anda dengan kode pembuatnya, menggunakan semua kemampuan yang diberikan Git kepada kami. Jika Anda benar-benar tersesat, Anda dapat mengganti cabang Anda sepenuhnya master di sebuah cabang solution lalu setel ulang direktori kerja Anda ke langkah kursus yang Anda perlukan.

Gunakan ini hanya jika Anda benar-benar membutuhkannya

Komit kode Anda

git add .
git commit -m "Backing up my work"

Perintah-perintah ini

• ganti nama master в master-backup;
• ganti nama solution в master;
• checkout ke cabang baru master dan menulis ulang isi direktori kerja;
• Buat cabang "solusi" dari "master" (yang dulunya adalah "solusi") jika Anda memerlukan cabang "solusi" di masa mendatang.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Setelah langkah-langkah ini dapat Anda gunakan git log master untuk mengetahui komit mana yang Anda perlukan.
Anda dapat mengatur ulang direktori kerja Anda ke komit ini seperti ini:

git reset --hard <the SHA you need>

Jika Anda puas dengan hasilnya, suatu saat Anda perlu mempublikasikan versi repositori Anda ke repositori jarak jauh. Jangan lupa untuk secara eksplisit menentukan cabang jarak jauh ketika Anda melakukan ini.

git push --force origin master

Harap dicatat bahwa kami menggunakan git push --force. Kecil kemungkinan Anda ingin melakukan hal ini terlalu sering, namun kami memiliki skenario yang sangat spesifik di sini dengan satu pengguna repositori yang, sebagai tambahan, memahami apa yang dia lakukan.

Mulai bekerja

Mari kita mulai menyusun daftar langkah CI kita. Biasanya Anda akan memulai langkah ini dengan memeriksa versi terbaru kode dari repositori jarak jauh, namun kami belum memiliki repositori lokal, jadi kami mengkloningnya dari repositori jarak jauh.

️ Tugas: memperbarui repositori lokal, membuat cabang dari master, mulai bekerja

1. Kloning repositori kursus dari <URL репозитория>.
2. Lari npm install di direktori repositori kursus; Kami membutuhkannya untuk menginstal Jest, yang kami gunakan untuk menjalankan tes.
3. Buat cabang dan beri nama feature. Beralih ke topik ini.

4. Tambahkan kode pengujian ke ci.test.js di antara komentar yang meminta saya melakukan ini.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Tambahkan teks dengan 4 langkah pertama ke file ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   Tim

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Buat komitmen pada cabang baru, bangun dan uji secara lokal

Kita akan menyiapkan pengujian untuk dijalankan sebelum melakukan, dan kemudian melakukan kode.

Skenario umum ketika pengujian dijalankan secara otomatis

• Lokal:
  • Terus menerus atau sebagai respons terhadap perubahan kode yang sesuai;
  • Saat menyimpan (untuk bahasa yang ditafsirkan atau dikompilasi JIT);
  • Selama perakitan (bila kompilasi diperlukan);
  • Saat berkomitmen;
  • Saat menerbitkan ke repositori bersama.

• Di server build atau lingkungan build:
  • Ketika kode dipublikasikan ke cabang/repositori pribadi.
  • Kode di thread ini sedang diuji.
  • Potensi hasil merger diuji (biasanya dengan master).
  • Sebagai tahap integrasi berkelanjutan/pipa pengiriman berkelanjutan

Biasanya, semakin cepat rangkaian pengujian dijalankan, semakin sering Anda mampu menjalankannya. Distribusi tahapan pada umumnya mungkin terlihat seperti ini.

• Pengujian unit cepat - selama pembuatan, dalam saluran CI
• Pengujian unit yang lambat, pengujian komponen dan integrasi yang cepat - saat dilakukan, dalam saluran CI
• Pengujian komponen dan integrasi yang lambat - dalam jalur CI
• Pengujian keamanan, pengujian beban, dan pengujian lain yang memakan waktu atau mahal - dalam pipeline CI/CD, namun hanya dalam mode/tahapan/pipeline tertentu dari build, misalnya, saat menyiapkan kandidat rilis atau saat dijalankan secara manual.

️Tugas

Saya sarankan menjalankan tes secara manual terlebih dahulu menggunakan perintah npm test. Setelah itu, mari tambahkan git hook untuk menjalankan pengujian pada commit. Ada satu kendala: Git hooks tidak dianggap sebagai bagian dari repositori dan oleh karena itu tidak dapat dikloning dari GitHub bersama dengan materi kursus lainnya. Untuk menginstal hook, Anda harus menjalankannya install_hook.sh atau salin file tersebut repo/hooks/pre-commit ke direktori lokal .git/hooks/.
Saat Anda melakukan commit, Anda akan melihat bahwa pengujian dijalankan dan pengujian tersebut memeriksa apakah kata kunci tertentu ada dalam daftar.

1. Jalankan pengujian secara manual dengan menjalankan perintah npm test di folder repositori kursus Anda. Verifikasi bahwa tes telah selesai.
2. Setel kait komit (kait pra-komit) dengan menjalankan install_hook.sh.
3. Komit perubahan Anda ke repositori lokal Anda.
4. Pastikan tes dijalankan sebelum melakukan.

Repositori Anda akan terlihat seperti ini setelah mengikuti langkah-langkah berikut.

Tim

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Publikasikan kode ke repositori jarak jauh atau cabang jarak jauh

Setelah mereka selesai bekerja secara lokal, pengembang biasanya membuat kode mereka tersedia untuk umum sehingga pada akhirnya dapat diintegrasikan dengan publik. Dengan GitHub, hal ini biasanya dicapai dengan menerbitkan karya ke salinan pribadi dari repositori (garpu pribadi) atau cabang pribadi.

• Dengan fork, pengembang mengkloning repositori bersama jarak jauh, membuat salinan jarak jauh pribadinya, yang juga dikenal sebagai fork. Ia kemudian mengkloning repositori pribadi ini untuk digunakan secara lokal. Ketika pekerjaan selesai dan komitmen dibuat, dia memasukkannya ke dalam forknya, di mana komitmen tersebut tersedia untuk orang lain dan dapat diintegrasikan ke dalam repositori umum. Pendekatan ini umumnya digunakan dalam proyek sumber terbuka di GitHub. Ini juga digunakan dalam kursus lanjutan saya [Kerja Tim dan CI dengan Git] (http://devops.redpill.solutions/).
• Pendekatan lain adalah dengan hanya menggunakan satu repositori jarak jauh dan hanya menghitung cabangnya master repositori bersama "dilindungi". Dalam skenario ini, masing-masing pengembang mempublikasikan kode mereka ke cabang repositori jarak jauh sehingga orang lain dapat melihat kode ini, jika semuanya beres, gabungkan dengan master repositori bersama.

Dalam kursus khusus ini, kita akan menggunakan alur kerja yang menggunakan cabang.

Mari publikasikan kode kita.

️Tugas

• Publikasikan perubahan ke cabang jarak jauh dengan nama yang sama dengan cabang kerja Anda

Tim

git push --set-upstream origin feature

Buat permintaan tarik

Buat permintaan tarik dengan judul Tinjauan langkah-langkah... Install feature seperti "cabang kepala" dan master seperti "cabang dasar".

Pastikan Anda telah menginstal master dalam dirinya garpu repositori Sebagai "cabang dasar", saya tidak akan menanggapi permintaan perubahan pada penyimpanan materi kursus.

Dalam istilah GitHub, "cabang dasar" adalah cabang tempat Anda mendasarkan pekerjaan Anda, dan "cabang kepala" adalah cabang yang berisi usulan perubahan.

Diskusikan perubahannya, tambahkan komitmen baru seiring diskusi berlanjut

Permintaan tarik (PR)

Permintaan tarik (PR) adalah cara untuk mendiskusikan dan mendokumentasikan kode, serta melakukan tinjauan kode. Permintaan tarik diberi nama berdasarkan cara umum mengintegrasikan perubahan individual ke dalam kode keseluruhan. Biasanya, seseorang mengkloning repositori resmi proyek jarak jauh dan mengerjakan kode secara lokal. Setelah ini, dia menempatkan kode tersebut di repositori jarak jauh pribadinya dan meminta mereka yang bertanggung jawab atas repositori resmi untuk mengambilnya (menarik) kodenya ke dalam repositori lokal mereka, tempat mereka meninjau dan mungkin mengintegrasikannya(bergabung) miliknya. Konsep ini juga dikenal dengan nama lain, misalnya permintaan penggabungan.

Anda sebenarnya tidak harus menggunakan fitur permintaan tarik dari GitHub atau platform serupa. Tim pengembangan mungkin menggunakan metode komunikasi lain, termasuk komunikasi tatap muka, panggilan suara, atau email, namun masih ada sejumlah alasan untuk menggunakan permintaan tarik gaya forum. Berikut beberapa di antaranya:

• diskusi terorganisir terkait perubahan kode tertentu;
• sebagai tempat untuk melihat masukan mengenai pekerjaan yang sedang berjalan baik dari autotester maupun rekan;
• formalisasi tinjauan kode;
• agar nantinya bisa mengetahui alasan dan pertimbangan dibalik potongan kode ini atau itu.

Biasanya Anda membuat permintaan tarik ketika Anda perlu mendiskusikan sesuatu atau mendapatkan masukan. Misalnya, jika Anda sedang mengerjakan fitur yang dapat diimplementasikan dengan lebih dari satu cara, Anda dapat membuat permintaan tarik sebelum menulis baris kode pertama untuk membagikan ide dan mendiskusikan rencana Anda dengan kolaborator. Jika pekerjaannya lebih sederhana, permintaan tarik dibuka ketika sesuatu telah dilakukan, dikomit, dan dapat didiskusikan. Dalam beberapa skenario, Anda mungkin ingin membuka PR hanya untuk alasan kontrol kualitas: untuk menjalankan pengujian otomatis atau memulai peninjauan kode. Apa pun keputusan Anda, jangan lupa untuk @mention orang-orang yang persetujuannya Anda inginkan dalam permintaan penarikan Anda.

Biasanya, saat membuat PR, Anda melakukan hal berikut.

• Tunjukkan apa yang Anda usulkan untuk diubah dan di mana.
• Tulis deskripsi yang menjelaskan tujuan perubahan. Anda mungkin ingin:
  • tambahkan sesuatu yang penting yang tidak terlihat jelas dari kode, atau sesuatu yang berguna untuk memahami konteksnya, seperti #bug yang relevan dan nomor commit;
  • @sebutkan siapa pun yang ingin Anda ajak bekerja sama, atau Anda dapat @sebutkan mereka di komentar nanti;
  • meminta rekan kerja untuk membantu dengan sesuatu atau memeriksa sesuatu yang spesifik.

Setelah Anda membuka PR, pengujian yang dikonfigurasi untuk dijalankan dalam kasus seperti itu akan dijalankan. Dalam kasus kami, ini akan menjadi rangkaian pengujian yang sama dengan yang kami jalankan secara lokal, namun dalam proyek sebenarnya mungkin ada pengujian dan pemeriksaan tambahan.

Harap tunggu sementara tes selesai. Anda dapat melihat status pengujian di bagian bawah diskusi PR di antarmuka GitHub. Lanjutkan ketika tes selesai.

️ Tambahkan catatan tentang keacakan daftar langkah CI

Daftar yang digunakan dalam kursus ini bersifat arbitrer dan subjektif, kami harus menambahkan catatan tentang hal ini.

️ Tugas: membuat permintaan tarik untuk komentar ini

1. Beralih ke cabang master.
2. Buat cabang bernama bugfix.
3. Tambahkan teks catatan di akhir file ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Komit perubahannya.
5. Publikasikan threadnya bugfix ke repositori jarak jauh.
6. Buat permintaan tarik bernama Menambahkan komentar dengan cabang kepala bugfix dan cabang dasarmaster.

Pastikan Anda telah menginstal master dalam dirinya garpu repositori Sebagai "cabang dasar", saya tidak akan menanggapi permintaan perubahan pada penyimpanan materi kursus.

Seperti inilah tampilan repositori Anda.

Tim

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Setujui permintaan tarik "Menambahkan komentar"

️Tugas

1. Buat permintaan tarik.
2. Klik "Gabungkan permintaan tarik".
3. Klik "Konfirmasi penggabungan".
4. Klik "Hapus cabang", kita tidak membutuhkannya lagi.

Ini adalah diagram penerapan setelah penggabungan.

️ Teruslah bekerja dan tambahkan tes

Berkolaborasi pada permintaan tarik sering kali menghasilkan pekerjaan tambahan. Ini biasanya merupakan hasil dari tinjauan kode atau diskusi, namun dalam kursus kita, kita akan memodelkannya dengan menambahkan item baru ke daftar langkah CI kita.

Integrasi berkelanjutan biasanya melibatkan beberapa cakupan pengujian. Persyaratan cakupan tes bervariasi dan biasanya ditemukan dalam dokumen yang disebut "pedoman kontribusi". Kami akan membuatnya tetap sederhana dan menambahkan tes untuk setiap baris di daftar periksa kami.

Saat menjalankan tugas, coba lakukan tes terlebih dahulu. Jika Anda menginstal dengan benar pre-commit kait sebelumnya, tes yang baru ditambahkan akan dijalankan, akan gagal, dan tidak ada yang akan dilakukan. Perhatikan bahwa ini adalah cara kami mengetahui bahwa pengujian kami sebenarnya menguji sesuatu. Menariknya, jika kita memulai dengan kode sebelum pengujian, lulus pengujian dapat berarti bahwa kode tersebut berfungsi seperti yang diharapkan, atau pengujian tersebut tidak benar-benar menguji apa pun. Selain itu, jika kita tidak menulis tes tersebut sejak awal, kita mungkin akan melupakannya sama sekali, karena tidak ada yang mengingatkan kita akan tes tersebut.

Pengembangan Berbasis Uji (TDD)

TDD merekomendasikan menulis tes sebelum kode. Alur kerja tipikal menggunakan TDD terlihat seperti ini.

1. Tambahkan tes.
2. Jalankan semua pengujian dan pastikan pengujian baru gagal.
3. Tulis kodenya.
4. Jalankan tes, pastikan semua tes lulus.
5. Perbaiki kode Anda.
6. Ulang.

Karena hasil pengujian yang gagal biasanya ditampilkan dengan warna merah, dan yang lulus biasanya ditampilkan dengan warna hijau, maka siklus ini disebut juga dengan refactor merah-hijau.

️Tugas

Pertama, coba lakukan pengujian dan biarkan gagal, lalu tambahkan dan lakukan teks daftar langkah CI itu sendiri. Anda akan melihat bahwa tesnya lulus ("hijau").
Kemudian publikasikan kode baru ke repositori jarak jauh dan lihat pengujian dijalankan di antarmuka GitHub di bagian bawah diskusi permintaan tarik dan pembaruan status PR.

1. Beralih ke cabang feature.

2. Tambahkan tes ini ke ci.test.js setelah panggilan terakhir it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Coba lakukan tes. Jika pre-commit hook dipasang, upaya komit akan gagal.
4. Kemudian tambahkan teks ini ke ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Buat dan terapkan perubahan secara lokal.
6. Posting perubahan ke cabang feature.

Anda sekarang seharusnya memiliki sesuatu seperti ini

Tim

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Gabungkan konflik

Buka Permintaan Perubahan Tinjauan langkah-langkah.

Meskipun kami tidak melakukan kesalahan apa pun dan pengujian untuk kode kami berhasil, kami tetap tidak dapat menggabungkan cabang tersebut feature и master. Itu karena thread yang lain bugfix telah digabungkan dengan master saat kami sedang mengerjakan PR ini.
Hal ini menciptakan situasi dimana cabang terpencil master memiliki versi yang lebih baru dari yang menjadi dasar cabang kami feature. Karena itu kita tidak bisa memundurkan HEAD begitu saja master ke akhir utas feature. Dalam situasi ini, kita perlu menggabungkan atau menerapkan komitmen feature rebase master. GitHub sebenarnya dapat melakukan penggabungan otomatis jika tidak ada konflik. Sayangnya, dalam situasi kami, kedua cabang memiliki perubahan yang bersaing dalam file ci.md. Situasi ini dikenal sebagai konflik penggabungan, dan kita perlu menyelesaikannya secara manual.

Gabungkan atau rebase

Bergabung

• Membuat komit gabungan tambahan dan menyimpan riwayat pekerjaan.
  • Mempertahankan komitmen asli cabang dengan stempel waktu dan penulis aslinya.
  • Menyimpan SHA dari komitmen dan link ke sana dalam diskusi permintaan perubahan.
• Membutuhkan resolusi konflik satu kali.
• Menjadikan cerita tidak linear.
  • Ceritanya mungkin sulit dibaca karena banyaknya cabang (mengingatkan pada kabel IDE).
  • Membuat proses debug otomatis menjadi lebih sulit, mis. git bisect kurang berguna - itu hanya akan menemukan komit gabungan.

rebase

• Pemutaran ulang dilakukan dari cabang saat ini di atas cabang dasar satu demi satu.
  • Komit baru dengan SHA baru dihasilkan, menyebabkan komit di GitHub cocok dengan permintaan penarikan asli, tetapi tidak dengan komentar terkait.
  • Komit dapat digabungkan kembali dan dimodifikasi dalam prosesnya, atau bahkan digabungkan menjadi satu.
• Berbagai konflik mungkin perlu diselesaikan.
• Memungkinkan Anda mempertahankan cerita linier.
  • Ceritanya mungkin lebih mudah dibaca asalkan tidak terlalu panjang tanpa alasan yang masuk akal.
  • Proses debug dan pemecahan masalah otomatis sedikit lebih mudah: memungkinkan git bisect, dapat membuat rollback otomatis menjadi lebih jelas dan dapat diprediksi.
• Memerlukan penerbitan cabang dengan komitmen yang dimigrasikan dengan sebuah bendera --force bila digunakan dengan permintaan tarik.

Biasanya, tim setuju untuk selalu menggunakan strategi yang sama ketika mereka perlu menggabungkan perubahan. Ini bisa berupa penggabungan "murni" atau komit "murni" di atas, atau sesuatu di antaranya, seperti melakukan komit di atas secara interaktif(git rebase -i) secara lokal untuk cabang yang tidak dipublikasikan ke repositori publik, tetapi digabungkan untuk cabang "publik".

Di sini kita akan menggunakan penggabungan.

️Tugas

1. Pastikan kodenya ada di cabang lokal master diperbarui dari repositori jarak jauh.
2. Beralih ke cabang feature.
3. Memulai penggabungan dengan cabang master. Konflik penggabungan karena perubahan yang bersaing pada ci.md.
4. Selesaikan konflik tersebut sehingga daftar langkah CI dan catatan tentang hal tersebut tetap ada dalam teks.
5. Publikasikan komit gabungan ke cabang jarak jauh feature.
6. Periksa status permintaan penarikan di UI GitHub dan tunggu hingga penggabungan terselesaikan.

Tim

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Kerja bagus!

Anda sudah selesai dengan daftarnya dan sekarang Anda harus menyetujui permintaan penarikan master.

️ Tugas: Menyetujui permintaan tarik "Tinjauan langkah"

1. Buka permintaan tarik.
2. Klik "Gabungkan permintaan tarik".
3. Klik "Konfirmasi penggabungan".
4. Klik "Hapus cabang" karena kita tidak membutuhkannya lagi.

Ini adalah gudang Anda saat ini

Kesalahan produk

Dikatakan bahwa “pengujian dapat digunakan untuk menunjukkan adanya kesalahan, namun tidak pernah untuk menunjukkan ketidakhadirannya”. Meskipun kami telah melakukan pengujian dan hasilnya tidak menunjukkan kesalahan apa pun, bug berbahaya menyusup ke dalam produksi.

Dalam skenario seperti ini, kita perlu memperhatikan:

• apa yang digunakan dalam produksi;
• kode di utas master dengan kesalahan, dari mana pengembang dapat memulai pekerjaan baru.

Haruskah saya memutar kembali atau memperbaikinya di versi berikutnya?

Roll back adalah proses penerapan versi sebelumnya yang diketahui baik ke produksi dan mengembalikan penerapan yang mengandung kesalahan. "Memperbaiki ke depan" adalah penambahan perbaikan pada master dan menerapkan versi baru sesegera mungkin. Karena API dan skema database berubah seiring kode diterapkan ke produksi, dengan pengiriman berkelanjutan dan cakupan pengujian yang baik, melakukan rollback biasanya jauh lebih sulit dan berisiko dibandingkan memperbaikinya di versi berikutnya.

Karena rollback tidak membawa risiko apa pun dalam kasus kami, kami akan mengambil rute ini, karena ini memungkinkan kami

• perbaiki kesalahan pada produk sesegera mungkin;
• memasukkan kode master segera cocok untuk memulai pekerjaan baru.

️Tugas

1. Beralih ke cabang master lokal.
2. Perbarui repositori lokal dari repositori jarak jauh.
3. Kembalikan komit penggabungan PR Tinjauan langkah-langkah в master.
4. Publikasikan perubahan ke repositori jarak jauh.

Ini adalah riwayat repositori dengan komit gabungan yang dikembalikan

Tim

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Tes mandiri

Pastikan bahwa ci.md tidak lagi berisi teks "bug licik" setelah mengembalikan komit gabungan.

Perbaiki daftar langkah CI dan kembalikan ke master

Kami telah sepenuhnya mengembalikan komit penggabungan cabang. feature. Kabar baiknya adalah kami sekarang tidak memiliki kesalahan master. Kabar buruknya adalah daftar langkah-langkah integrasi berkelanjutan yang berharga juga hilang. Jadi, idealnya, kita perlu menerapkan perbaikan pada commit dari feature dan mengembalikannya ke master beserta perbaikannya.

Kita dapat mendekati masalah ini dengan berbagai cara:

• mengembalikan komit yang membatalkan penggabungan feature с master;
• move commit dari yang pertama feature.

Tim pengembangan yang berbeda menggunakan pendekatan yang berbeda dalam kasus ini, namun kami akan memindahkan komitmen yang berguna ke cabang terpisah dan membuat permintaan penarikan terpisah untuk cabang baru ini.

️Tugas

1. Buat thread bernama feature-fix dan beralih ke itu.

2. Migrasikan semua komitmen dari cabang sebelumnya feature ke utas baru. Selesaikan konflik penggabungan yang terjadi selama migrasi.

   

3. Tambahkan uji regresi ke ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Jalankan pengujian secara lokal untuk memastikan pengujian tersebut tidak gagal.
5. Hapus teks "dengan bug licik" di ci.md.
6. Tambahkan perubahan pengujian dan daftar langkah perubahan pada indeks dan terapkan.
7. Publikasikan cabang ke repositori jarak jauh.

Anda akan mendapatkan sesuatu yang mirip dengan ini:

Tim

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Buat permintaan tarik.

Buat permintaan tarik dengan judul Memperbaiki fitur tersebut... Install feature-fix seperti "cabang kepala" dan master seperti "cabang dasar".
Harap tunggu sementara tes selesai. Anda dapat melihat status ujiannya di bagian bawah pembahasan PR.

Pastikan Anda telah menginstal master dalam dirinya garpu repositori Sebagai "cabang dasar", saya tidak akan menanggapi permintaan perubahan pada penyimpanan materi kursus.

Setujui permintaan tarik "Memperbaiki fitur"

Terima kasih atas koreksinya! Harap setujui perubahan tersebut master dari permintaan tarik.

️Tugas

1. Klik "Gabungkan permintaan tarik".
2. Klik "Konfirmasi penggabungan".
3. Klik "Hapus cabang" karena kita tidak membutuhkannya lagi.

Inilah yang harus Anda miliki saat ini.

Selamat!

Anda telah menyelesaikan semua langkah yang biasanya dilakukan orang selama integrasi berkelanjutan.

Jika Anda melihat ada masalah dengan kursus atau mengetahui cara memperbaikinya, silakan buat masalah di repositori dengan materi kursus. Kursus ini juga memiliki versi interaktif menggunakan GitHub Learning Lab sebagai platform.

Sumber: www.habr.com