Layanan microser. Versi dalam Integrasi dan Penerapan Sistem Berkelanjutan Studi Kasus CI / CD Menggunakan TFS

Masalah

Untuk proyek-proyek besar dan kompleks secara teknis, di mana, sebagai suatu peraturan, banyak tim terdistribusi bekerja secara bersamaan, ada masalah yang terkenal dari perangkat lunak versi sedang dikembangkan, yang diselesaikan oleh perusahaan yang berbeda secara berbeda.

Saat ini, sejumlah klien dan mitra kami mengirimkan rilis terbaru (CI / CD) ke Production secara manual dengan menginstal versi terbaru / terkini dari perangkat lunak mereka, setelah sebelumnya mengujinya dengan seluruh lingkungan. Misalnya, dengan memasok aplikasi iOS, Android, dll. Jika kita berbicara tentang perangkat lunak klien, atau dengan memperbarui gambar buruh pelabuhan di lingkungan buruh pelabuhan jika kita berbicara tentang backend. Untuk proyek besar dan penting di mana keputusan untuk merilis versi baru dalam Produksi setiap kali dibuat oleh Manajer Proyek, keputusan seperti itu dibenarkan dan tidak terlalu mahal, terutama jika rilis tidak sering dirilis. Namun, untuk lingkungan pengembangan pengujian (lingkungan Dev / Stage), penggunaan alat "manual" mengarah pada kompleksitas proyek, kemungkinan gangguan tayangan kepada Pelanggan, dan sebagainya. Mungkin ada banyak alasan untuk ini, termasuk ketidakkonsistenan dalam versi berbagai wadah pada perangkat lunak middleware atau tidak adanya riwayat terperinci tentang rilis.

Kami harus memastikan ini secara pribadi dan mengalami banyak kesulitan pada proyek besar, di mana 6-8 versi baru perangkat lunak di backend dan 2-3 versi perangkat lunak di frontend dalam sistem CI dirilis setiap hari, di mana para insinyur pengujian tidak dapat secara objektif mengatasi beban dan selalu ada kekurangan pemahaman tentang versi perangkat lunak pada frontend / backend yang dianggap stabil saat ini.

Pengalaman kami

Perusahaan kami menggunakan berbagai sistem CI / CD dalam pekerjaannya, pilihan yang sering ditentukan oleh persyaratan Pelanggan. Misalnya, spesialis kami sering menemukan sistem CI / CD seperti Jenkins, TeamCity, Travis CI, Circle CI, Gitlab CI, Atlassian Bamboo, di mana kadang-kadang kami bekerja sepenuhnya pada infrastruktur pelanggan. Dengan demikian, dengan pendekatan ini, masalah dengan solusi versi sepenuhnya ada pada Pelanggan.

Ketika mengembangkan solusi untuk pelanggan, ketika kami memiliki kesempatan untuk melakukan ini pada infrastruktur kami sendiri, kami menggunakan TFS versi 2018 sebagai dasar untuk sistem Continuous Integration / Continuous Delivery. Ini memungkinkan kami untuk menyelesaikan tugas utama menciptakan siklus pengembangan perangkat lunak yang lengkap, yaitu:

• Pernyataan tugas (Masalah, Bug, Tugas) berdasarkan pendekatan pengembangan perangkat lunak yang digunakan dalam proyek saat ini;
• Penyimpanan kode sumber proyek;
• Penyebaran infrastruktur build-agent untuk majelis untuk OS yang berbeda (Windows, Linux, MacOS);
• Merakit proyek dalam mode "manual" dan CI;
• Penempatan proyek dalam mode "manual" dan CD;
• Proyek pengujian;
• Pembentukan data mengenai waktu yang dihabiskan oleh karyawan pada proyek dan sejumlah fungsi tambahan yang kami terapkan menggunakan TFS Extensions dari desain kami sendiri dan dengan menambahkan statika ke WIT (dalam formulir ini, TFS menggantikan Redmine perusahaan kami dan menyederhanakan pengumpulan statistik, laporan, dll., Dalam konteks proyek) )

Dalam hal ini, akan logis untuk memberikan solusi untuk masalah versi ke TFS, menyelesaikan fungsionalitas TFS untuk tugas-tugas kami dan keinginan Pelanggan. Akibatnya, tugas membangun sistem versi untuk proyek arsitektur layanan mikro diselesaikan oleh alat TFS dengan menyesuaikan berbagai skrip pembuatan dan mengatur lingkungan uji / rilis.

Solusinya: menggunakan TFS dan alat pihak ketiga

Jadi, kita membutuhkan sistem versi untuk proyek arsitektur microservice untuk mengatur lingkungan pengujian dan rilis.

Sebagai data awal kami memiliki:

• Orkestrasi - kami menggunakan gerombolan buruh pelabuhan terutama untuk mengurangi penggunaan alat pihak ketiga lainnya. Pada saat yang sama, ada konverter untuk mengonversi konfigurasi - misalnya, utilitas Kompose , yang akan memungkinkan Anda untuk menggunakan Kubernetes jika perlu.
• Build agents - VM berdasarkan pada server Linux.
• Sumber repositori - Git berbasis TFS.
• Penyimpanan gambar - register buruh pelabuhan di VM.

Untuk pertanyaan tentang nama build

• Adalah logis untuk menggunakan standar penamaan yang ada, misalnya, seperti Spesifikasi Versi Semantik .
• Kami mengikuti nama ini ketika memulai proses pembuatan versi rilis secara manual, karena jika tidak, Anda tidak akan bisa mendapatkan nama yang benar secara otomatis (kecuali Anda memasukkannya ke dalam kode secara manual, yang lagi-lagi hanya memiliki sedikit kaitan dengan ideologi CI).
• Dalam mode CI untuk versi perangkat lunak "debug" kami menggunakan nama-nama berikut pada proyek yang berbeda:
  
  
  1. Ekstensi TFS bawaan
  2. Penomoran berdasarkan tanggal saat ini dan nomor build pada hari itu;
  3. Jumlah komit yang memulai pembangunan.

Solusi spesifik, misalnya, dapat dilihat berdasarkan contoh layanan Kalkulator , dibuat dalam Javascript, dan beberapa proyek yang tersedia untuk umum.

Algoritma keputusan

1. Di TFS2018, buat proyek yang disebut SibEDGE Semver dan impor repositori ke repositori lokal


Gambar 1 - proyek SibEDGE Semver di repositori di TFS 2018

2. Buat file Dockerfile dengan deskripsi assembly node.js untuk kebutuhan kita ( tautan ).

FROM node:7 WORKDIR /usr/src/app COPY package.json app.js LICENSE /usr/src/app/ COPY lib /usr/src/app/lib/ LABEL license MIT COPY tests tests ENV NODE_ENV dev RUN npm config set strict-ssl false RUN npm update && \ npm install -g mocha CMD ["mocha", "tests/test.js", "--reporter", "spec"] 

Script 1 - Dockerfile untuk membangun bangunan

3. Di bangku tes (dengan docker terpasang), tempat kami berencana untuk menyebarkan lingkungan kami, buat gugus segerombolan. Dalam kasus kami, ini akan terdiri dari satu server.

 $ docker swarm init 

4. Buat file-yml dengan deskripsi layanan microser untuk kebutuhan kita ( tautan ).
Perhatikan bahwa vm-docker-registry.development.com:5000 adalah repositori internal untuk proyek ini, yang kami persiapkan sebelumnya. Agar tempat pengujian dapat menggunakan repositori ini, perlu mendaftarkan sertifikat ssl pada dudukan di /etc/docker/certs.d/ <repositori name> /ca.crt folder

 version: '3.6' services: #--- # Portainer for manage Docker #--- portainer: image: portainer/portainer:1.15.3 command: --templates http://templates/templates.json -d /data -H unix:///var/run/docker.sock networks: - semver-network ports: - 9000:9000 volumes: - /var/run/docker.sock:/var/run/docker.sock #--- #----Service Calculator Test# #--- semver-calc: image: vm-docker-registry.development.com:5000/calculator:latest networks: - semver-network #--- #----Pminder - Nginx# #--- nginx: image: nginx:1.9.6 depends_on: - mysql ports: - "8888:80" - "6443:443" networks: - semver-network # #----------------------------- # START NoSQL - Redis. #--- redis: image: redis:4.0 networks: - semver-network ports: - "8379:6379" # # END NoSQL - Redis. #--- #----Pminder - DB# #--- mysql: image: mysql:5.7 ports: - "3306:3306" environment: MYSQL_ROOT_PASSWORD: 'ODdsX0xcN5A9a6q' MYSQL_DATABASE: 'semver' MYSQL_USER: 'user' MYSQL_PASSWORD: 'uXcgTQS8XUm1RzR' networks: - semver-network #--- #----PhpMyAdmin # #--- phpmyadmin: image: phpmyadmin/phpmyadmin depends_on: - mysql environment: PMA_HOST: 'mysql' PMA_USER: 'user' PMA_PASSWORD: 'uXcgTQS8XUm1RzR' ports: - "8500:80" - "8600:9000" networks: - semver-network #--- networks: semver-network: 

Script 2 adalah isi dari file semver.yml, yang merupakan file proyek docker-compose.

5. Buat deskripsi build di TFS2018 (Build Definition).

6. Tindakan pertama dari skrip kami adalah membangun gambar kontainer buruh pelabuhan:


Gambar 2 - Membangun gambar untuk bangunan kami di TFS 2018

7. Kirim gambar wadah buruh pelabuhan yang dibuat pada mesin build ke repositori internal untuk proyek ini:


Gambar 3 - Menyimpan buruh pelabuhan-gambar untuk perakitan kami di repositori TFS 2018

8. Untuk seluruh lingkungan di bangku tes dalam file deskripsi layanan microsoft, ubah nama gambar ke yang baru:


Gambar 4 - Mengganti nama gambar dalam skrip build untuk build kami di TFS 2018

9. Di bangku tes, salin gambar wadah buruh pelabuhan yang dibuat dari repositori internal dan perbarui layanan di kerumunan buruh pelabuhan:


Gambar 5 - Menyebarkan container docker dengan skrip build untuk build kami dari gambar di TFS 2018

Akibatnya, ketika kami keluar ke repositori TFS, kami memiliki file yml dengan versi rilis gambar buruh pelabuhan, yang pada gilirannya memiliki nama rilis untuk seluruh proyek.

10. Mari kita pergi ke bangku tes dan memeriksa pekerjaan layanan dan memastikan bahwa layanan Kalkulator telah diperbarui dan menggunakan versi baru perakitan.

 $ docker service ls 

Gambar 6 - Memperbarui layanan Kalkulator dan memeriksa versinya saat ini di bangku tes kami

Dengan demikian, dalam penyimpanan gambar registri docker kami, kami memiliki serangkaian gambar dari berbagai versi layanan microser (dalam kasus khusus ini, versi hanya satu layanan microser diubah). Dengan meluncurkan proses penyebaran terpisah (melalui skrip yang mengubah file deskripsi yml), kapan saja Anda bisa mendapatkan lingkungan yang Anda butuhkan untuk pengujian di bangku tes dan mentransfer konfigurasi ini ke divisi QA. Setelah pengujian (regresi, memuat dll.) Kami mendapatkan informasi bahwa layanan microser dari versi tertentu bekerja secara stabil di bangku tes dengan versi rilis layanan microser lainnya dari versi ini dan itu, dan keputusan akhir telah dibuat tentang apa yang dapat atau tidak diperbarui dudukan rilis ke versi baru.

Ringkasan - apa yang Anda dapatkan di pintu keluar

Berkat penerapan versi dalam proyek-proyek dengan arsitektur microservice, hasil berikut tercapai:

• jumlah kekacauan dalam versi telah menurun;
• kecepatan penyebaran lingkungan baru dalam proyek telah meningkat;
• kualitas majelis telah meningkat dan tingkat kesalahan di dalamnya telah menurun;
• peningkatan transparansi pengembangan untuk Manajer Proyek dan Pelanggan;
• interaksi antar departemen telah meningkat;
• Ada arahan baru dalam karya DevOps.

PS Terima kasih kepada kolega saya Kirill B. untuk membantu saya menulis artikel ini.