Kami membuat proyek cloud untuk pengembangan - platform yang dapat menyederhanakan kehidupan para pengembang, pengembang, penguji, pemimpin tim, dan spesialis lain yang terlibat dalam proses pengembangan sebanyak mungkin. Produk ini bukan untuk sekarang dan bukan untuk besok, dan kebutuhan untuk itu baru saja dibentuk.
Gagasan utama adalah bahwa Anda dapat menggunakan pipa dengan alat yang sudah dikonfigurasikan, tetapi pada saat yang sama dengan kemungkinan membuat sejumlah pengaturan, yang perlu Anda lakukan hanyalah menggunakan kode.
Dari mana penyimpangan semacam itu datang? Kami melihat tren yang jelas bahwa sekarang kecepatan penyebaran proyek baru mempengaruhi pasar. Perdagangan tergantung pada seberapa cepat rilis dikirimkan. Dari seberapa cepat bug akan diperbaiki, seberapa cepat relung baru akan dilibatkan. Pada awal 2018, perusahaan global "451 Research" melakukan survei teknologi mana yang akan menjadi prioritas untuk pengembangan. Sepuluh teratas mencakup pembuatan wadah dan teknologi manajemen, serta arsitektur aplikasi dan server mikro tanpa server, menyalip bahkan topik hype seperti blockchain.
Dan sekarang kami memiliki beberapa pertanyaan untuk Anda.
Bagan dari survei:
Apakah itu perlu?
Penggunaan wadah dalam pengembangan produk baru memiliki kelebihan dan kekurangan. Apakah akan menggunakan teknologi ini atau tidak harus ditentukan berdasarkan tugas yang ditetapkan. Untuk sejumlah tugas, penggunaan wadah tidak dapat disingkirkan, dan untuk beberapa, mereka hanya berlebihan. Misalnya, untuk situs dengan lalu lintas rendah, arsitektur sederhana dua server akan cukup. Tetapi jika pertumbuhan pembangunan yang signifikan direncanakan, serta peningkatan besar pengunjung dalam waktu singkat, maka dalam hal ini layak mempertimbangkan infrastruktur menggunakan wadah.
Menggunakan wadah memiliki beberapa keunggulan:
- Setiap aplikasi berjalan secara terpisah dalam wadahnya sendiri, yang meminimalkan masalah terkait konfigurasi.
- Keamanan aplikasi juga dicapai dengan mengisolasi setiap wadah.
- Karena kenyataan bahwa wadah menggunakan kernel sistem operasi, sekarang OS tamu tidak diperlukan, karena sejumlah besar sumber daya dibebaskan.
- Juga, karena penggunaan kernel sistem operasi dan karena Anda tidak perlu bergantung pada hypervisor, wadah memerlukan sumber daya yang jauh lebih sedikit dibandingkan tumpukan lainnya.
- Sekali lagi, karena kenyataan bahwa kontainer tidak memerlukan sistem operasi tamu, mereka mudah untuk bermigrasi dari satu server ke yang lain.
- Karena setiap aplikasi berjalan dalam wadah yang terisolasi, mudah untuk mentransfer dari mesin lokal ke cloud;
- Sangat murah untuk memulai dan menghentikan wadah karena penggunaan kernel sistem operasi.
Sehubungan dengan semua hal di atas, kami percaya bahwa teknologi kontainerisasi saat ini adalah tumpukan tercepat, paling hemat sumber daya dan paling aman. Karena keunggulan wadah, Anda dapat memiliki lingkungan yang sama baik pada mesin lokal maupun dalam produksi, yang memfasilitasi proses integrasi berkelanjutan dan pengiriman kontinu.
Manfaat wadah sangat meyakinkan sehingga pasti akan digunakan untuk waktu yang lama.
Apa hubungan cloud dengan pengembangan?
Di dunia ideal pengembang, kode komit apa pun harus diluncurkan ke produksi dengan mengklik tombol, seolah-olah dengan sulap.
Kami melakukannya seperti ini: ada Gitlabchik dengan tugas dan sumber. Ketika Anda perlu mengumpulkan sesuatu - GitLab Runner. Kami bekerja pada Git Flow, semua fitur di cabang terpisah. Ketika cabang memasuki repositori, tes pada kode ini diluncurkan di GitLab. Jika tes lulus, pengembang utas ini dapat membuat permintaan penggabungan, bahkan permintaan untuk tinjauan kode. Setelah peninjauan, cabang diterima, digabung ke dalam dev-cabang, tes melewatinya lagi. Saat menggunakan, GitLab Runner mengumpulkan wadah Docker dan menggulungnya ke server staging, di mana ia dapat diklik dan bersukacita. Dan di sini adalah lelucon pertama - kita melihat kode dengan tangan kita untuk kepatuhan dengan fungsional dan ini adalah hal pertama yang kita perbaiki. Setelah itu, kami menyuntikkan kode ke cabang rilis. Dan baginya, kami meluncurkan versi terpisah pra-produktif dari solusi kami, yang ditonton oleh pelanggan bisnis kami. Setelah versi pra-instal pada pra-prod, kami menggulungnya menjadi produksi dan bergulir ke node produk. Ada catatan rilis dan laporan bug yang dibuat secara otomatis. Kecepatan perakitan lebih dari 30 menit, sekarang urutannya lebih kecil. Kami telah memilih satu set alat untuk diri kami sendiri dan sekarang berpikir tentang bagaimana membuat SaaS siap pakai yang sama.
Bagi kami, proses rilis khas untuk rilis adalah sebagai berikut:
- Menetapkan tujuan untuk implementasi fitur baru
- Pelokalan kode
- Membuat perubahan sesuai dengan tugas. Menulis tes otomatis sebelum pembuatan.
- Verifikasi kode, baik manual maupun swa-uji
- Menggabungkan kode ke cabang dev
- Bangun cabang dev
- Menyebarkan infrastruktur uji
- Menyebarkan rilis pada infrastruktur uji
- Menjalankan pengujian, fungsional, integrasi, dll.
- Jika ada bug, segera selesaikan di dev-branch
- Bermigrasi cabang dev ke cabang master
Berikut adalah diagram dengan detail untuk proses kami:
Sebenarnya, pertanyaan pertama - tolong beri tahu kami di mana Anda menyapu rake macam apa itu dan seberapa universal atau tidaknya skema ini. Jika Anda menggunakan alur kerja yang sangat berbeda dari ini, maka tambahkan beberapa kata, mengapa demikian, silakan.
Produk apa yang kita rencanakan?
Kami memutuskan untuk tidak menyalin Amazon dalam hal ini, tetapi untuk melakukan pengembangan kami dengan mempertimbangkan spesifikasi pasar. Segera buat reservasi bahwa semua perhitungan adalah pendapat subjektif kami berdasarkan analisis kami. Kami terbuka untuk dialog yang konstruktif dan siap untuk mengubah peta jalan produk.
Ketika menganalisis pipa yang ada dari Amazon, kami sampai pada kesimpulan bahwa ia memiliki kemampuan yang luar biasa, tetapi penekanannya ada pada tim perusahaan yang sangat besar. Tampaknya bagi kami bahwa untuk meluncurkan layanan microser di Docker, itu terlalu panjang, lebih daripada jika, misalnya, diluncurkan di Kubernetes, karena ada tempat untuk mengkonfigurasi konfigurasi internal, mendefinisikan perjanjian internal, dll. dan semua ini perlu dipahami untuk waktu yang lama.
Di sisi lain, ada, misalnya, Heroku, tempat Anda dapat menggunakan dalam satu klik. Tetapi karena fakta bahwa proyek, sebagai suatu peraturan, cukup kuat, dengan layanan pihak ketiga, pada titik tertentu menjadi perlu untuk meluncurkan gambar buruh pelabuhan khusus dengan layanan DBaaS dan semua ini tidak sesuai dengan Herocku karena harganya mahal baik tidak nyaman.
Kami ingin menemukan opsi lain. Berarti emas. Bergantung pada jenis proyek dan tugas, memberi Anda satu set alat yang sudah dikonfigurasikan sebelumnya yang telah diintegrasikan ke dalam pipa tunggal, sambil meninggalkan kemungkinan perubahan besar dalam pengaturan dan kemampuan untuk mengganti alat itu sendiri.
Jadi apa jadinya?
Ecosystem, yang mencakup portal dan seperangkat alat dan layanan untuk meminimalkan interaksi pengembang dengan tingkat infrastruktur. Anda menentukan parameter lingkungan yang tidak terkait dengan lingkungan fisik:
- Lingkungan pengembangan (sistem manajemen konfigurasi, sistem pengaturan tugas, repositori untuk menyimpan kode dan artefak, pelacak tugas)
- CI - Integrasi Berkelanjutan (perakitan, infrastruktur dan orkestrasi)
- QA - Jaminan Kualitas (pengujian, pemantauan dan penebangan)
- Pementasan - Lingkungan Integrasi / Prerelease Loop
- Produksi - Sirkuit produktif
Memilih alat, kami fokus pada praktik terbaik di pasar.
Kami akan membangun infrastruktur dengan Stage dan Prod menggunakan Docker dan Kubernetes dengan fitur debu paralel.
Ini akan terjadi berulang - pada tahap pertama, layanan direncanakan yang akan memungkinkan Anda untuk mengambil file Docker dari proyek, kemudian mengumpulkan wadah yang diperlukan dan meletakkannya ke Kubernetes.
Kami juga berencana untuk memberikan perhatian khusus pada layanan untuk memantau proses pengembangan dan pengiriman berkelanjutan. Apa yang kami maksud dengan layanan ini? Ini adalah peluang untuk membuat model KPI hierarkis dengan indikator seperti% cakupan oleh unit test, waktu rata-rata untuk menghilangkan insiden atau cacat, waktu rata-rata dari komitmen hingga pengiriman, dll.
Pengumpulan data sumber dari berbagai sistem - pengujian sistem manajemen, manajemen tugas, komponen CI / CD, alat pemantauan infra, dll.
Dan yang paling penting adalah menunjukkan dalam bentuk yang memadai tersedia untuk analisis cepat - dashboard dengan kemungkinan menelusuri, analisis komparatif indikator.
Apa yang ingin kita lakukan
Sebenarnya, saya benar-benar ingin mendengar dari Anda tentang semua ini dan rencana kami untuk langkah-langkah. Sekarang mereka adalah:
- Infrastruktur dan Orkestrasi - Docker & Kubernetes
- Pengaturan tugas, kode dan penyimpanan artefak, pelacak tugas - Gitlab, Redmine, S3
- Produksi & Pengembangan - Koki / Kemungkinan
- Majelis - Jenkins
- Pengujian - Selenium, LoadRunner
- Pemantauan dan Penebangan - Prometheus & ELK
- Ngomong-ngomong, bagaimana Anda melihat jika di dalam platform akan ada pilihan - jika Anda mau, pilih Jenkins, tidak mau - GitLab Runner?
- Atau tidak masalah apa yang ada di dalamnya, yang terpenting adalah semuanya dibangun, diuji, dan disebarkan dengan benar?
Bagaimana seseorang bisa membantu?
Produk ini akan dikembangkan untuk pengembang dalam negeri. Jika sekarang Anda memberi tahu kami bagaimana melakukannya, kemungkinan itu akan dimasukkan dalam rilis.
Tolong beri tahu saya tumpukan apa yang Anda gunakan saat ini. Anda dapat - dalam komentar atau melalui email ke team@ts-cloud.ru.
UPD: untuk kenyamanan, kami membuat kuesioner singkat dalam formulir Google - di
sini .
Selanjutnya, kami akan terus memberi Anda informasi terbaru tentang perkembangan ini - dan pada titik tertentu kami akan memberikan akses kepada para peserta yang membantu beta (pada kenyataannya, akses gratis ke sumber daya komputasi awan yang baik sebagai imbalan atas umpan balik).