İş öğesi türü için iş akışını değiştirme

Azure DevOps Server | Azure DevOps Server 2022

İş ve ekip süreçlerinizi desteklemek için iş öğesi türünün (WIT) iş akışını değiştirin. WIT'ler yazılım geliştirmeyi desteklemek için tüm iş türlerinin (gereksinimler, görevler, kod hataları) izlenmesini destekler.

İş akışı, ekip üyelerinin gerçekleştirdiği işin mantıksal ilerlemesini ve regresyonunu belirler. Ayrıca Durum ve Neden alanlarının açılan menülerinde görüntülenen değerleri de belirtir. Daha fazla bilgi için bkz . İşlemler ve işlem şablonları hakkında.

Ürün İş Listesi Öğesi İş Akışı (Scrum süreç şablonu)

Not

Bu makalede bir iş akışı durumunun nasıl özelleştirileceği açıklanmaktadır. Belirli bir iş öğesine atanan Durumu değiştirmek için şu makalelerden birine bakın: Pano, Devam eden çalışmayı izleme veya Görev panosu, Görev durumunu güncelleştirme. Ayrıca birçok iş öğesi için Durum toplu güncelleştirmesini de gerçekleştirebilirsiniz.

derleme işlem hattı iş akışları hakkında bilgi için CI/CD ile çalışmaya başlama'ya bakın.

İş öğesi türü için XML tanımını güncelleştirme

WIT özelleştirmeyi yeni kullanıyorsanız aşağıdakilere dikkat edin:

• bir iş öğesi türünün herhangi bir yönünü özelleştirmek için XML tanımını güncelleştirin. Daha fazla bilgi için bkz Tüm WITD XML öğeleri referansı.
• Yeni iş öğesi deneyimini kullanan web formunu özelleştiriyorsanız bkz. WebLayout ve Denetim öğeleri.
• Visual Studio ile kullanmak üzere bir istemci formunu özelleştiriyorsanız Düzen XML öğesi başvurusuna bakın.
• İş öğesi izleme web formunu özelleştirme bölümünde açıklanan adımların sırasını izleyin.

İş akışını özelleştirmek için şu iki adımı izleyin:

1. WORKFLOW WIT tanımının bölümünü bu konuda açıklandığı gibi değiştirin.

2. Yeni iş akışı durumlarını meta durumlarla eşlemek için işlem yapılandırmasını değiştirin.

   Çevik araç sayfasında görünen wit için iş akışını değiştirdiğinizde bu ikinci adım gereklidir. Bu WIT'ler Gereksinim veya Görev kategorilerine aittir. Durum kategorileri hakkında daha fazla bilgi için bkz . İş akışı durumları ve durum kategorileri.

İş akışı tasarım yönergeleri

önce durumları ve aralarındaki geçerli geçişleri belirleyerek iş akışını tanımlayın. WORKFLOW WIT tanımının bölümü geçerli durumları, geçişleri, geçişlerin nedenlerini ve bir ekip üyesi bir iş öğesinin durumunu değiştirdiğinde çalıştırılacak isteğe bağlı eylemleri belirtir.

Genel olarak, her durumu bir ekip üyesi rolüyle ve bu roldeki bir kişinin durumunu değiştirmeden önce iş öğesini işlemek için gerçekleştirmesi gereken bir görevle ilişkilendirin. Geçişler, durumlar arasındaki geçerli ilerlemeleri ve regresyonları tanımlar. Bir ekip üyesinin bir iş öğesini bir durumdan diğerine neden değiştirdiğini açıklayan nedenler belirlenir ve iş akışının bir aşamasında iş öğesinin geçişini otomatikleştiren eylemler desteklenir.

Örneğin, test eden varsayılan Çevik işlemi temel alan yeni bir hata açtığında Durum değerini Yeni olarak ayarlayın. Geliştirici, hatayı düzeltirken Durumu Etkin olarak değiştirir ve düzeltildikten sonra geliştirici durumunu Çözüldü olarak değiştirir ve Neden alanının değerini Sabit olarak ayarlar. Düzeltmeyi doğruladıktan sonra, test eden hatanın durumunu Kapalı olarak, Neden alanı ise Doğrulandı olarak değiştirir. Test eden, geliştiricinin hatayı düzeltmediğini belirlerse, test eden hatanın durumunu Etkin olarak değiştirir ve Nedeni Sabit Değil veya Test Başarısız olarak belirtir.

Bir iş akışını tasarlarken veya değiştirirken aşağıdaki yönergeleri göz önünde bulundurun:

• Her ekip üyesi rolünün bir iş öğesi üzerinde belirli bir eylem yaptığı benzersiz bir durum tanımlamak için STATE öğesini kullanın. Ne kadar çok durum tanımlarsanız, o kadar fazla geçiş tanımlamanız gerekir. Durumları tanımladığınız diziden bağımsız olarak, Durum alanının açılan menüsünde alfasayısal sırada görünürler.

  Web portalındaki kapsam veya pano sayfalarında görünen bir iş öğesi türüne durum eklerseniz, durumu bir durum kategorisine de eşlemeniz gerekir. Daha fazla bilgi için bkz . İş akışı durumları ve durum kategorileri.

• Bir durumdan diğerine her geçerli ilerleme ve gerileme için TRANSITION öğesini bir geçiş tanımlamak üzere kullanın.

  En azından her durum için bir geçiş ve null durumdan ilk duruma geçiş tanımlayın.

  Atanmamış durumdan (null) ilk duruma yalnızca bir geçiş tanımlayabilirsiniz. Yeni bir iş öğesini kaydettiğinizde, işlem bu öğeyi otomatik olarak ilk duruma atar.

  Ekip üyesi bir iş öğesinin durumunu değiştirdiğinde, bu değişiklik geçişi ve seçili durum ve geçiş için gerçekleştirilecek şekilde tanımladığınız eylemleri tetikler. Kullanıcılar, yalnızca mevcut durum için tanımladığınız geçişlere göre geçerli olan durumları belirtebilir. Buna ek olarak, ACTION öğesinin alt öğesi olan bir öğe TRANSITION, iş öğesinin durumunu değiştirebilir.

• Her geçiş için DEFAULTREASON öğesini kullanarak varsayılan bir neden tanımlayın. öğesini kullanarak REASON istediğiniz sayıda isteğe bağlı neden tanımlayabilirsiniz. Bu değerler, Neden alanının açılan menüsünde görünür.

• İş öğesi durum değiştirdiğinde, geçiş yaparken veya bir kullanıcı belirli bir nedeni seçtiğinde uygulanacak kurallar belirtebilirsiniz. Bu kuralların çoğu, FIELDS tanımının altındaki WORKITEMTYPE bölümündeki alanları tanımlarken uygulayabileceğiniz koşullu kurallara ek olarak gelir. Daha fazla bilgi için bu konunun devamında yer alan İş akışı değişikliği sırasında alanları güncelleştirme bölümüne bakın.

• Durumlara ve nedenlere atadığınız adlar harf büyüklüğüne duyarlı değildir.

  İş öğesi formu veya sorgu düzenleyicisindeki Durum ve Neden alanlarının açılan menüleri, iş öğesi türünün bölümünde atanan WORKFLOW değerleri görüntüler.

İş akışı diyagramı ve kod örneği

Aşağıdaki kod örneği, Çevik süreç şablonundaki Hata WIT tanımının WORKFLOW öğesini gösterir. Bu örnek üç durumu ve beş geçişi tanımlar. STATE Öğeler Etkin, Çözüldü ve Kapalı durumlarını belirtir. İlerleme ve regresyon geçişleri için tüm olası birleşimler, biri hariç üç durum için tanımlanır. Kapalı'dan Çözüldü'ye geçiş tanımlanmadı. Bu nedenle, iş öğesi kapatılırsa ekip üyeleri bu türdeki bir iş öğesini çözümleyemez.

Bu örnek , , DEFAULTREASONREASONve ACTIONöğelerinin FIELDtümünü listelemez.

Örnek İş Akışı Durum Diyagramı — Çevik Hata WIT'i

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

Durumların sayısını ve türlerini belirleme

Geçerli durumların sayısına ve türlerine, bu türdeki iş öğelerinin var olmasını istediğiniz ayrı mantıksal durumların sayısına göre karar verin. Ayrıca, farklı ekip üyeleri farklı eylemler gerçekleştiriyorsa, üye rolüne dayalı bir durum tanımlamayı göz önünde bulundurun. Her durum, bir ekip üyesinin bir sonraki duruma taşımak için iş öğesinde gerçekleştirmesi gereken bir eyleme karşılık gelir. Her durum için belirli eylemleri ve bu eylemleri gerçekleştirmesine izin verilen ekip üyelerini tanımlayın.

Aşağıdaki tabloda, bir özelliğin ilerleme durumunu ve belirtilen eylemleri gerçekleştirmesi gereken geçerli kullanıcıları izleyen dört durum örneği verilmiştir:

Durum / Eyalet	Geçerli kullanıcı	Yapılacak eylem
Teklif Edildi	Proje yöneticisi	Herkes bir özellik iş öğesi oluşturabilir. Ancak, yalnızca proje yöneticileri iş öğesini onaylayabilir veya reddedebilir. Proje yöneticisi bir özelliği onaylarsa, proje yöneticisi iş öğesinin durumunu Etkin olarak değiştirir; aksi takdirde, bir ekip üyesi bunu kapatır.
Aktif	Geliştirme lideri	Geliştirme lideri özelliğin geliştirilmesini denetlemektedir. Özellik tamamlandığında geliştirme lideri, özellik iş öğesinin durumunu Gözden Geçir olarak değiştirir.
İnceleyin	Proje yöneticisi	Proje yöneticisi, ekibin uyguladığı özelliği gözden geçirir ve uygulama tatmin ediciyse iş öğesinin durumunu Kapalı olarak değiştirir.
Kapalı	Proje yöneticisi	Kapatılan iş öğelerinde ek bir eylem gerçekleşmesi beklenmemektedir. Bu öğeler arşivleme ve raporlama amacıyla veritabanında kalır.

Not

Tüm durumlar, belirttiğiniz sıradan bağımsız olarak, belirli bir türdeki iş öğesinin formdaki listede alfabetik sırada görünür.

Geçişleri tanımlama

Ekip üyelerinin bir iş öğesini değiştirebileceği başlangıç ve hedef durumları, geçerli durum ilerlemelerini ve gerilemelerini tanımlayarak kontrol edersiniz. Bir durumdan başka bir duruma geçiş tanımlamazsanız, ekip üyeleri belirli bir durumdaki belirli bir tür iş öğesini belirli bir durumdan başka bir belirli duruma değiştiremez.

Aşağıdaki tablo, bu konunun önceki bölümlerinde açıklanan dört durumdan her biri için geçerli geçişleri ve her birinin varsayılan nedenini tanımlar.

Durum / Eyalet	Duruma geçiş	Varsayılan neden
Teklif Edildi	Etkin (ilerleme)	Geliştirme için onaylandı
	Kapalı (ilerleme)	Onaylanmadı
Aktif	Gözden geçirme (ilerleme)	Kabul ölçütleri karşılandığında
İnceleyin	Kapalı (ilerleme)	Özellik tamamlandı
	Etkin (regresyon)	Gereksinimleri karşılamıyor
Kapalı	Önerilen (regresyon)	Onay için yeniden gözden geçirme
	Etkin (regresyon)	Hatayla kapatıldı

öğesinin for ve TRANSITION özniteliklerini kullanarak bir durumdan diğerine geçiş yapmasına izin verilen kişileri kısıtlayabilirsiniz. Aşağıdaki örnekte gösterildiği gibi, test ediciler bir hatayı yeniden açabilir ancak geliştiriciler açamaz.

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>  

Nedenleri belirtin

Ekip üyesi State alanını değiştirdiğinde, bu geçiş için varsayılan nedeni tutabilir veya ek seçenekler tanımlarsanız farklı bir neden belirtebilir. DEFAULTREASON öğesini kullanarak bir ve yalnızca bir varsayılan neden belirtin. Ek nedenler yalnızca ekibin verileri izlemesine veya bildirmesine yardımcı olursa ekleyin.

Örneğin, bir geliştirici bir hatayı çözümlediğinde aşağıdaki nedenlerden birini belirtebilir: Düzeltildi (Varsayılan), Ertelenmiş, Yinelenen, Tasarlandığı Gibi, Yeniden Oluşturulamıyor veya Kullanımdan kaldırıldı. Her neden, test edenin hatayla ilgili olarak gerçekleştirmesi gereken belirli bir eylemi belirtir.

Not

Tüm nedenler, öğeleri belirttiğiniz REASON sıradan bağımsız olarak, belirli bir türdeki iş öğeleri için iş formundaki listede alfabetik sırada görünür.

Aşağıdaki örnekte, ekip üyesinin bir hatayı neden çözümleyebileceğini tanımlayan öğeler gösterilmektedir:

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>  

Eylemleri belirtme

Genel olarak, ekip üyeleri Durum alanı için farklı bir değer belirtip iş öğesini kaydederek iş öğesinin durumunu değiştirir. Ancak, bu geçiş gerçekleştiğinde iş öğesinin durumunu otomatik olarak değiştiren bir öğe de tanımlayabilirsiniz ACTION . Aşağıdaki örnekte gösterildiği gibi, bir geliştiricinin sürüm denetiminde denetlediği dosyalarla ilişkili olan hata iş öğelerinin otomatik olarak çözülmesi gerektiğini belirtebilirsiniz:

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>  

ACTION Microsoft Visual Studio Uygulama Yaşam Döngüsü Yönetimi'nin başka bir yerinde veya Visual Studio Uygulama Yaşam Döngüsü Yönetimi'nin dışında olaylar gerçekleştiğinde (örneğin, çağrıları izleyen bir araçtan) belirli bir türdeki iş öğelerinin durumunu otomatik olarak değiştirmek için öğesini kullanın. Daha fazla bilgi için bkz . EYLEM.

İş akışı değişikliği sırasında alanı güncelleştirme

Aşağıdaki olaylar gerçekleştiğinde alanları güncelleştiren kurallar tanımlayabilirsiniz:

• Kuralın tüm geçişler ve bu duruma girme nedenleri için uygulanmasını istediğiniz durumlarda altında STATE bir alan kuralı atayın.

• Kuralın bu geçiş için ne zaman uygulanmasını istediğinizi ve bu geçişi yapmanın tüm nedenlerini içeren bir alan kuralı TRANSITION atayın.

• Belirli bir nedenle kuralların uygulanmasını istediğinizde DEFAULTREASON veya REASON altında bir alan kuralı atayın.

  Bir alanın her zaman aynı değeri içermesi gerekiyorsa, bu alanı tanımlayan öğesinin FIELD altında kuralı tanımlayın. Kural kullanımı hakkında daha fazla bilgi için bkz . Kurallar ve kural değerlendirmesi.

  Herhangi bir iş öğesi türü için tanımladığınız koşulların sayısını en aza indirin. Her koşullu kural, bir ekip üyesi bir iş öğesini her kaydettiğinde gerçekleşen doğrulama işlemine karmaşıklık ekler. Karmaşık kural kümeleri, iş öğesini kaydetmek için gereken süreyi artırabilir.

  Aşağıdaki örneklerde, MSF Çevik Yazılım Geliştirme için işlem şablonundaki sistem alanlarına uygulanan bazı kurallar gösterilmektedir.

Durum değiştiğinde alanın değerini değiştirme

Bir iş öğesinin Durum alanının değerini Etkin olarak ayarladığınızda ve iş öğesini kaydettiğinizde, Etkinleştirilen ve Atanan alanlarının değerleri otomatik olarak geçerli kullanıcının adına ayarlanır. Bu kullanıcının Team Foundation Server Geçerli Kullanıcılar grubunun bir üyesi olması gerekir. Etkinleştirilmiş Tarih alanının değeri de otomatik olarak ayarlanır. Aşağıdaki örnekte, bu kuralı zorunlu kılan öğeler gösterilmektedir:

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>  

Başka bir alanın değeri değiştiğinde alanın değerini temizleme

Bir iş öğesinin State alanının değerini Etkin olarak ayarladığınızda ve iş öğesini kaydettiğinizde EMPTY , öğe Aşağıdaki örnekte gösterildiği gibi Kapalı Tarih ve Kapanış Tarihi alanlarını otomatik olarak null olarak ayarlar ve salt okunur hale getirir.

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>  

Başka bir alanın içeriğine göre alan tanımlama

Bir iş öğesinin Durum alanının değerini Çözüldü olarak değiştirip iş öğesini kaydettiğinizde, Çözümlenen Neden alanının değeri kullanıcının Neden alanında belirttiği değere ayarlanır. Aşağıdaki örnekte, bu kuralı zorunlu kılan öğeler gösterilmektedir:

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>  

İlgili içerik

• İş akışı durumları ve durum kategorileri
• İş izleme deneyiminizi özelleştirme
• Atama, iş akışı veya pano değişikliklerine göre sorgulama
• İş öğesi formunu tasarlama
• İş öğesi türlerini içeri aktarma, dışarı aktarma ve yönetme

Araç desteği

Kullanıcılarınızın iş akışını görselleştirmesine yardımcı olmak için Visual Studio Market'ten Durum Modeli Görselleştirme uzantısını yükleyin.