Mercurial ile kod incelemeleri için önerilen işlem

Genelde Perforce ve SmartBear'ın Kod Ortak Çalıştırıcısını kullandık Big Corpve şimdi bazı projeler için Mercurial kullanacağız.

Code Collaborator desteği Mercurial (sürüm 5'i kullanıyoruz) ve kod inceleme için en iyi zamanın (kesin / sunucuya gönderme sırasında) işleminin en iyi / verimli zaman olduğunu belirlemeye çalışıyorum

Teşekkürler

code-reviews mercurial

— cbrulak
kaynak

Muhtemelen iki soruyu ayırmalısınız. (a) buraya ait, ancak (b) muhtemelen

— blueberryfields

Teşekkürler @blueberryfields. Aslında sorunu düzeltti, bin / hg.cmd dosya yol ve hiçbir exe olmak sorun oldu.

— cbrulak

Yanıtlar:

Aslında son zamanlarda şirketimde neredeyse aynı şeyi yaşadık. İşte yaptıklarımız:

Tüm depolarımızın merkezi bir kopyasını tek bir sunucuda tutarız. Geliştiriciler kodu "teslim almak" istediklerinde, bu sunucuya gider ve oradaki depolardan klonlar. Benzer şekilde, geliştirme döngüsü tamamlandığında, kod da orada uygun depoya aktarılır.
Biz ayrı istikrarlı gelen depoları geliştirme depoları. İstikrarlı bir depoya aktarılmadan önce kodun gözden geçirilmesini istiyoruz. (Bu önemlidir, çünkü kararlı depolarımızın şu anda üretimde çalışmakta olan kodu içermesini ve yalnızca bekleyen kod tanıtımlarından farklı olmasını zorunlu kılıyoruz.)

Kod incelemesini zorunlu kılmak için bir pretxnchangegroupkanca yazdık ( HG Kitabında belgelenmiştir ). Bu kanca çalıştığında veri havuzunu kod değişiklikleri kalıcı olsaydı görebilir, ancak aynı zamanda itmeyi önleme yeteneği de verir. Temel olarak, süreç aşağıdaki gibidir:

Geliştirici istikrarlı depoya bir itme başlatır (evet, bu gerçekten ilk adımdır)
Kanca çalışır ve (HG günlüğünü çalıştırarak) işleme dahil tüm değişiklik kümelerinin bir listesini kapar. Daha sonra, bu değişiklik kümelerinin bir kod incelemesine dahil edilip edilmediğini görmek için oluşturduğumuz bir veritabanını sorgular. (Tablo, bir değişiklik kümesinin karmasını kod inceleme kimliğiyle eşleştirir).
- Bu değişiklik kümelerinden herhangi biri ilk kez görüldüyse, yeni bir Kod İncelemesi (Kod Ortak Çalıştırıcı komut satırı kullanarak) oluşturur ve bu değişiklik kümelerini bu kod incelemesinin kimliğiyle veritabanına kaydederiz.
- Değişiklik kümelerinin bazılarını (ancak hepsini değil) gördüysek, yeni inceleme kümelerini mevcut incelemeye eklemek ve bu yeni değişiklik kümelerini veritabanına kaydetmek için (Kod Ortak Çalışanı) komutunu çalıştırırız.
- Tüm değişiklikler veritabanında bulunursa (yani, kod incelemesine hepsi eklenmişse), kod incelemesinin durumunun Tamamlandığını doğrularız. Bununla birlikte, yeni bir değişiklik kümesi varsa (veya kod incelemesi tamamlanmadıysa), kanca sıfır olmayan bir durum koduyla çıkar (Mercurial'ın işlemi geri almasına neden olur) ve geliştiriciye açıklayan Standart Hata ile ilgili kolay bir mesaj verir kod incelemesinin tamamlanması gerektiği.

Temel olarak, bu geliştiriciye oldukça aerodinamik bir süreç sağlar (tek yapmaları gereken bir hg push) ve kod incelemesinin oluşturulmasını (ve incelemeye ek değiştirilmiş dosyalar yüklemek) tamamen otomatikleştirirken, tüm kodların incelenmesini sağlar .

Not: Bu oldukça basit bir işlemdir (ve bizim için nispeten yeni), bu yüzden herkes için işe yaramayabilir ve henüz karşılaşmadığımız bazı tasarım hataları olabilir. Ama şimdiye kadar oldukça iyi çalıştı.

— Ryan
kaynak

Kod gözden geçirmeden önce kararlı ortamınızı kontrol etme kararınızı açıklar mısınız? Bana göre istikrarlı bir yanlış isim gibi görünüyor.

— Ürdün

Muhtemelen cevaptan net değildi, ancak tüm değişiklikler kod incelemesine eklenmedikçe ve inceleme tamamlanmadığı sürece aslında depoya girmiyor. Kanca sıfır olmayan bir çıkış koduyla çıkarsa Mercurial, itilen tüm değişiklikleri geri alır. Böylece, bu özel kanca sadece inceleme için farkları almak için değil, aynı zamanda değişikliklerin depoya girmesine izin verilmeden önce incelemeyi uygulamak için çok uygun bir yer sağlar.

— Ryan

Vay. Senin için işe gelebilir miyim?

— Zengin

@Ryan - Pretxnchangegroup kancasını nasıl uygularız, sağladığınız bağlantı nasıl uygulanabileceği hakkında ayrıntılı bir açıklama yapmaz, takip etmemiz gereken fonksiyon şablonunu vermez, kancayı nereye koyacağımızı. Python deneyimim yok. Lütfen beni doğru bir kaynağa veya pretxnchangegroup hook şablonuna yönlendirebilir misiniz? Ta

— Simple-Solution

Havuz yapınıza nasıl sahip olduğunuza ve neyi başarmaya çalıştığınıza bağlıdır. DVCS dünyasında gerçekten "ön itme" anlamına gelen "ön taahhüt" incelemelerini yapmayı tercih ediyoruz. DVCS'ler bu ortamda daha güzeldir (geleneksel SCM'lerle karşılaştırıldığında), yerel değişikliklerinizi kaydetmek ve çalışma alanınızı geri almak için yerleşik bir işleve sahiptirler, böylece başka bir şey üzerinde çalışabilirsiniz.

İtme sonrası incelemeler yapmak istiyorsanız, ideal iş akışı büyük ölçüde depo yapınıza bağlıdır. Örneğin, Git depo düzenleri hakkında bu makalede açıklanan yapıya benzeyen bir depo yapısı olduğunu varsayalım . Bu durumda, birleştirilen değişiklikleri incelemek isteyebilirsiniz develop. Unsur branşlarındaki bireysel taahhütler gözden geçirmenin anlamlı olmayabilir. Açıkçası hepsi hotfixesde içine birleşmeleri ile birlikte gözden geçirilmelidir master.

Bunun yerine, insanların doğrudan check-in yaptığı tek bir entegrasyon şubeniz varsa, o şubeye yapılan tüm pushları incelemek istersiniz. Bu muhtemelen biraz daha az verimlidir, ancak yine de işe yarayabilir. Bu ortamda, bir sürümü kesmeden önce itilen tüm değişikliklerin gözden geçirildiğinden emin olmanız gerekir. Daha hileli olabilir.

B) gelince önerebileceğim tek şey doğrudan SmartBear desteğini (support@smartbear.com) e-postayla göndermektir. Yol sorunlarınızı çözmenize yardımcı olmaktan memnuniyet duyarız (evet, SmartBear için çalışıyorum), ancak bu soruda sorununuzu çözmek için yeterli bilgi yok. Normal işlem sadece yükleyiciyi çalıştırmaktır ve her şey çalışır. Görünüşe göre bu süreçte bir şeyler ters gitti.

— Brandon DuRette
kaynak