Apakah ide yang baik untuk menginstal Mercurial di server Anda dan hg menarik untuk menyebarkan?


13

Saya baru saja memulai pekerjaan baru bulan lalu dan sepertinya mereka TIDAK memiliki kendali sumber untuk kode mereka. Mereka mengandalkan cadangan yang diambil penyedia hosting untuk mereka.

Setelah berbicara sedikit, saya meyakinkan bos saya bahwa kita harus benar-benar menggunakan kontrol sumber dan setelah saya memberikan seminar singkat tentang itu, seluruh tim ada di papan; mereka mencintai Mercurial.

Jadi sekarang ini cara kami bekerja:

º----------BitBucket
º---------/
º--------/

Saya sendiri dan tiga pengembang lainnya hg pulldari BitBucket, buat perubahan kami, lalu hg pushke BitBucket.

Sekarang untuk penyebaran, seseorang akan perlu untuk FTP file terbaru ke server produksi.

Saya sedang berpikir untuk menginstal Mercurial di server kami, dan menggunakan hg clone(selanjutnya hg pull) untuk menjaga agar versi tetap terbaru pada produksi.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

Apakah ini ide yang bagus? Adakah potensi jebakan yang mungkin tidak saya lihat? Adakah yang pernah melakukan hal serupa di sini? Bagaimana Anda menggunakan aplikasi kerangka PHP besar (Kami menggunakan Moodle)?


Itu ide yang luar biasa. Mengapa Anda ragu?
Nikolay Fominyh

Ini adalah proses yang banyak orang lakukan dan ternyata dianggap "normal" sehingga Microsoft sekarang telah membangun dukungan untuk melakukan Git (dengan dukungan hg mungkin di masa depan) berbasis disebarkan ke layanan Azure mereka.
Alan Barber

Jawaban:


12

Ini tentu saja merupakan ide yang baik dan ini adalah metode yang umum digunakan untuk penyebaran. Anda mungkin ingin menggunakan cabang stabil untuk tujuan penyebaran sambil menjaga batang untuk pengembangan yang sedang berlangsung sehingga Anda dapat menguji cabang stabil sebelum Anda menyebarkannya ke dalam produksi.

Satu-satunya masalah dapat muncul ketika Anda memiliki informasi sensitif di basis kode Anda (seperti kunci API dll) yang tidak ingin Anda unggah ke server pihak ketiga (dalam kasus Anda itu adalah Bitbucket). Dalam hal ini skrip sederhana yang dijalankan setelah Anda menarik data dari repositori untuk mengembalikan data sensitif di tempat yang benar akan menyelesaikan masalah itu.


10

Pikiran bahwa strategi penyebaran ini bukan atom. Mungkin saja beberapa file sudah diperbarui sementara file lain mungkin masih dalam kondisi lama ketika aplikasi sedang dipukul. Ini dapat menyebabkan efek samping yang tidak terduga.

Cara untuk melakukan penyebaran atom adalah dengan menggunakan symlink. Buat direktori yang berisi file baru. ketika semuanya siap, ubah symlink untuk direktori yang digunakan. Jika Anda tetap menggunakan versi lama, Anda juga dapat dengan mudah mengembalikannya.


3
Anda dapat dengan mudah mengembalikan, itulah tujuan VCS.
Rob

1
belum tentu - maka Anda perlu menjaga konfigurasi atau beberapa file yang dihasilkan yang mungkin tergantung versi dan sistem dalam VCS. Selain itu Anda harus menggunakan tag (yang tidak disebutkan dalam proses yang dijelaskan dalam pertanyaan) ke e ale untuk kembali ke versi kerja yang dikenal.
johannes

2

Kemungkinan lain (menurut saya lebih baik) : gunakan server build / server integrasi berkesinambungan.

Penjelasan singkat singkat: ini adalah server (bisa in-house, tidak perlu di internet) yang Anda atur untuk memantau repositori Anda, dan setiap kali ada perubahan baru dalam repo, server membuat kode Anda ( AFAIK ini tidak diperlukan dalam PHP) , jalankan tes unit dan gunakan kode Anda ke server web.

Untuk informasi lebih lanjut, periksa tautan ini:

Ada banyak produk berbeda untuk CI di luar sana , tetapi satu-satunya yang saya gunakan sejauh ini adalah TeamCity . Sangat mudah untuk diatur ... sebenarnya, ini yang pertama saya coba, dan saya sangat menyukainya sehingga saya tetap menggunakannya.


Solusi murah alternatif:

Jika menyiapkan server pembangunan terlalu banyak usaha atau jika Anda ingin lebih mengontrol kapan tepatnya situs Anda digunakan, cukup buat file skrip (Batch / Powershell di Windows, atau yang serupa di Linux / Mac) yang menarik versi terbaru dari repositori Anda dan FTP di server produksi.

Pada dasarnya, ini sama dengan server build, hanya lebih sederhana.


Tidak peduli bagaimana tepatnya Anda menyelesaikannya pada akhirnya ... pastikan untuk mengotomatiskannya entah bagaimana!

Anda ingin dapat menggunakan dengan satu klik / dengan mengetik satu perintah, sehingga SEMUA ORANG dapat melakukannya tanpa harus tahu sesuatu yang istimewa, dan tanpa membuat kesalahan - bahkan dalam kasus bencana atau di bawah tekanan.


1

Kami melakukan ini, atau hal-hal yang mirip dengan ini. @Johannes nonatomik menyebutkan sudut adalah satu masalah, meskipun secara realistis hal itu terjadi begitu cepat, itu harus baik-baik saja dan ada cara untuk mengatasi hal ini saat ia menunjukkan.

Mungkin yang lebih penting daripada non-atomisitas ini adalah "bagaimana Anda mengelola pembaruan skema basis data" - menggunakan kode yang buruk dengan cara ini membuat memperbaikinya dengan mudah. Masalah besarnya adalah ketika Anda menggunakan pembaruan yang mengubah database yang ingin Anda putar kembali. Atau jika Anda membuat pembaruan yang buruk dan merusak data.

Masalah lain yang kami miliki dengan alat DCVS (bukan menggunakan SVN) adalah bahwa Anda sekarang memiliki salinan seluruh basis kode pada mesin di tempat penyerang berpotensi mengambil. Dan juga basis kode DCVS itu bisa menjadi ukuran yang cukup berat, yang bisa jadi masalah jika Anda membayar untuk penyimpanan dan / atau cadangan. Kami masih menggunakan SVN untuk penyebaran akhir karena alasan ini.


1

Ini adalah ide yang bagus, namun ingatlah yang berikut:

  • Cobalah untuk tidak melakukan di server (walaupun beberapa kali jarang masuk akal untuk melakukan ini, misalnya menginstal plugin atau menambahkan aset konten)
  • Gunakan server staging atau penyebaran repositori sekunder untuk pengujian
  • Berhati-hatilah agar hg update -Ctidak memengaruhi produksi (mis. Hapus file penting)
  • Memiliki cabang produksi dan pengembangan, hanya menggunakan cabang produksi
  • Perlakukan aset sebagai cadangan (mis. Gambar untuk konten,) dan abaikan data pengguna (mis. Lampiran / unggahan, cache, dll)
  • Selalu ada hg statuskeluaran bersih di server (ini akan membantu Anda memastikan Anda mengabaikan hal-hal sebagai cache)
  • Jangan menggunakan repositori di folder web. Gunakan symlink dari luar ruang publik (mis. Ln -s / myrepo / src / web / public_html / myapp)
  • Hati-hati jangan sampai membuat file konfigurasi versi (khusus dengan kata sandi basis data atau lainnya)
  • Jangan gunakan alih-alih cadangan produksi, ini adalah cadangan pengembangan untuk kode produksi , bukan data produksi

Akhirnya, saya pikir hal yang paling berharga untuk menambahkan DVCS ke proses penerapan Anda adalah bahwa ini akan menambah keamanan untuk penyebaran Anda, kadang-kadang peretas menyuntikkan kode berbahaya ke barang-barang Anda dan Anda benar-benar tidak memiliki cara untuk mendeteksi dengan mudah tanpa sesuatu seperti kontrol versi ( didistribusikan secara khusus, karena aspek yang didistribusikan ke VCS memudahkan untuk memeriksa integritas file Anda).

Aku sudah beberapa situs mendapatkan hack beberapa kali, memiliki Mercurial membantu saya litterally membatalkan hacks ini dengan hanya mengeluarkan hg update -Cdi server (tentu saja Anda mungkin ingin melakukan hg statusdan mendapatkan file yang terkena untuk analisis nanti).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.