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

Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

İş ve ekip süreçlerinizi desteklemek için bir iş öğesi türünün (WIT) iş akışını değiştirebilirsiniz. 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ştireceğ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 Kapsam Öğesi İş Akışı (Scrum işlem şablonu)

Not

Bu makalede bir iş akışı durumunun nasıl özelleştirileceği açıklanır. Bunun yerine, belirli bir iş öğesine atanan Durumu değiştirmek istiyorsanız şu makalelerden birine bakın: Kanban panosu, 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 bkz. CI/CD kullanmaya başlama.

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

WIT özelleştirmeyi yeni kullanıyorsanız aşağıdakileri not edin:

• İş öğesi türünün herhangi bir yönünü özelleştirmek için XML tanımını güncelleştirmeniz gerekir. XML tanımı Tüm WITD XML öğeleri başvurusunda açıklanmıştır
• Yeni iş öğesi deneyimini kullanan web formunu özelleştiriyorsanız, WebLayout ve Control öğelerine başvurmak istersiniz
• Bir istemci formunu Visual Studio ile kullanmak üzere özelleştiriyorsanız, Düzen XML öğesi başvurusuna başvurmak istersiniz
• İş öğesi izleme web formunu özelleştirme bölümünde açıklanan adım dizisini 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 edinmek için bkz . İş akışı durumları ve durum kategorileri.

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

önce durumları ve bunlar arasındaki geçerli geçişleri tanımlayarak iş akışını tanımlarsınız. WORKFLOW WIT tanımının bölümü geçerli durumları, geçişleri, geçişlerin nedenlerini ve bir ekip üyesi iş öğesinin durumunu değiştirdiğinde gerçekleştirilecek 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şkilendirirsiniz. Geçişler, durumlar arasındaki geçerli ilerlemeleri ve regresyonları tanımlar. Nedenler, bir ekip üyesinin bir iş öğesini neden bir durumdan diğerine değiştirip iş akışında bir iş öğesinin geçişinin otomasyonunu desteklediğini tanımlar.

Örneğin, bir test kullanıcısı varsayılan Çevik işlemi temel alan yeni bir hata açtığında Durum Yeni olarak ayarlanır. Geliştirici, hatayı düzeltirken Durum değerini 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:

• bir iş öğesi üzerinde STATE belirli bir eylem gerçekleştirecek her ekip üyesi rolü için benzersiz bir durum tanımlamak için öğ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 listelenirler.

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

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

  En azından, her durum için bir geçiş ve null durumdan ilk duruma geçiş tanımlamanız gerekir.

  Atanmamış durumdan (null) ilk duruma yalnızca bir geçiş tanımlayabilirsiniz. Yeni bir iş öğesini kaydettiğinizde, öğe otomatik olarak ilk duruma atanır.

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

• Her geçiş için öğesini kullanarak DEFAULTREASON varsayılan bir neden tanımlarsınız. öğ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üntülenir.

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

• Durumlara ve nedenlere atadığınız adlar büyük/küçük harfe duyarsızdır.

  İş öğ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 işlem şablonu için Hata WIT tanımı için öğesini gösterir WORKFLOW . Bu örnek üç durumu ve beş geçişi tanımlar. STATE Öğeler Etkin, Çözüldü ve Kapatıldı durumlarını belirtir. İlerleme ve regresyon geçişleri için tüm olası birleşimler, biri dışında üç durum için tanımlanır. Kapalı'dan Çözümlendi'ye geçiş tanımlanmadı. Bu nedenle, iş öğesi kapatılırsa ekip üyeleri bu türdeki bir iş öğesini çözümleyemez.

Bu örnek , , REASONACTIONve FIELDöğelerinin DEFAULTREASONtümünü listelemez.

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

<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>

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

Geçerli durumların sayısını ve türlerini, bu türdeki iş öğelerinin var olmasını istediğiniz ayrı mantıksal durumların sayısına göre belirlersiniz. Ayrıca, farklı ekip üyeleri farklı eylemler gerçekleştiriyorsa, üye rolüne dayalı bir durum tanımlamayı düşünebilirsiniz. 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ımlamanız gerekir.

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

Durum	Geçerli kullanıcı	Gerçekleştirilecek eylem
Önerilen	Proje yöneticisi	Herkes bir özellik iş öğesi oluşturabilir. Ancak, iş öğesini yalnızca proje yöneticileri onaylayabilir veya onaylayabilir. 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.
Etkin	Geliştirme lideri	Geliştirme lideri özelliğin geliştirilmesini denetler. Özellik tamamlandığında geliştirme müşteri adayı, özellik iş öğesinin durumunu Gözden Geçir olarak değiştirir.
Gözden geçirme	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.
Kapatıldı	Proje yöneticisi	Kapatılan iş öğelerinde ek bir eylem gerçekleşmesi beklenmez. 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

Geçerli durum ilerlemelerini ve regresyonlarını tanımlarsanız, ekip üyelerinin iş öğesini değiştirebileceği durumları ve durumları denetleyebilirsiniz. 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 tabloda, bu konuda daha önce açıklanan dört durumdan her biri için geçerli geçişler ve her birinin varsayılan nedeni tanımlanmaktadır.

Durum	Duruma geçiş	Varsayılan neden
Önerilen	Etkin (ilerleme)	Geliştirme için onaylandı
	Kapalı (ilerleme)	Onaylanmadı
Etkin	Gözden geçirme (ilerleme)	Kabul ölçütleri karşılandığında
Gözden geçirme	Kapalı (ilerleme)	Özellik tamamlandı
	Etkin (regresyon)	Gereksinimleri karşılamıyor
Kapatıldı	Önerilen (regresyon)	Onay için yeniden düşünün
	Etkin (regresyon)	Kapalı hatası

öğesinin for ve değil özniteliklerini kullanarak bir durumdan diğerine geçiş yapmasına izin verilenleri TRANSITION 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 kullanıcı bu geçişin varsayılan nedenini koruyabilir veya ek seçenekler tanımlarsanız farklı bir neden belirtebilir. öğesini kullanarak DEFAULTREASON bir ve yalnızca bir varsayılan neden belirtmeniz gerekir. Ek nedenleri yalnızca ekibin verileri izlemesine veya raporlamaya yardımcı olması durumunda belirtmeniz gerekir.

Örneğin, bir geliştirici bir hatayı giderirken 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 diziden bağımsız olarak, belirli bir türdeki iş öğelerinin 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şkiliyse hata iş öğelerinin otomatik olarak çözümleneceğini belirtebilirsiniz:

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

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 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 kullanabilirsiniz ACTION . 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.

• Kuralların yalnızca belirli bir nedenle uygulanmasını istediğiniz veya altında bir alan kuralı DEFAULTREASONREASON atayın.

  Bir alanın her zaman aynı değeri içermesi gerekiyorsa, kuralı bu alanı tanımlayan öğesinin FIELD altında tanımlarsınız. Kural kullanımı hakkında daha fazla bilgi edinmek 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 indirmeyi denemelisiniz. Eklediğiniz her koşullu kuralla, bir ekip üyesi iş öğesini her kaydettiğinde gerçekleşen doğrulama işleminin karmaşıklığını artırırsınız. 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ğeri Etkin olarak ayarlandığında ve iş öğesi kaydedildiğinde, 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 ü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ğeri Etkin olarak ayarlandığında ve iş öğesi kaydedildiğinde, aşağıdaki örnekte gösterildiği gibi, öğeyi kullanırsanız EMPTY Kapalı Tarih ve Kapanış Tarihi alanları otomatik olarak null olarak ayarlanır ve salt okunur hale getirilir.

<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ğeri Çözüldü olarak değiştiğinde ve iş öğesi kaydedildiğinde, Çö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 makaleler:

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

Araç desteği

Visual Studio Market'ten Durum Modeli Görselleştirme uzantısını yükleyerek kullanıcılarınızın iş akışını görselleştirmesini destekleyebilirsiniz.