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

  • Makale

Azure DevOps Server 2022 - Azure DevOps Server 2019

İş ve ekip süreçlerinizi desteklemek için 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)

Ürün kapsamı öğesi iş akışı, Scrum işlemi

Not

Bu makalede bir iş akışı durumunun nasıl özelleştirileceği açıklanmaktadır. Bunun yerine, belirli bir iş öğesine atanan Durumu değiştirmek istiyorsanız, ş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 bkz . CI/CD'yi kullanmaya başlama.

İş öğ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ş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
  • Visual Studio ile kullanmak üzere bir istemci formunu ö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ı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ı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, 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 eden varsayılan Çevik işlemi temel alan yeni bir hata açtığında Durum Yeni olarak ayarlanır. 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:

  • 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 kategorisine de eşlemeniz gerekir. Daha fazla bilgi 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çili 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 alt öğesi olan bir öğe TRANSITION, 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ü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, 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 bölümüne bakın.

  • Durumlara ve nedenlere atadığınız adlar büyük/küçük harfe 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 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 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 , , REASONACTIONve FIELDöğelerinin DEFAULTREASONtümünü listelemez.

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

Hata iş akışı durumları, Çevik işlem şablonu

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

State Geçerli kullanıcı Action to perform
Teklif Edildi Proje yöneticisi Herkes bir özellik iş öğesi oluşturabilir. Ancak, yalnızca proje yöneticileri iş öğesini 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 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.
Closed 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

Geçerli durum ilerlemelerini ve regresyonlarını tanımlarsanız ekip üyelerinin iş öğesini değiştirebileceği durumları denetlersiniz. 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.

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

öğesinin for ve not özniteliklerini kullanarak bir durumdan diğerine geçiş yapmasına izin verilen kişileri 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 tek ve tek bir varsayılan neden belirtmeniz gerekir. Ek nedenleri yalnızca ekibin verileri izlemesine veya raporlamaya yardımcı olması durumunda belirtmelisiniz.

Ö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şkilendirilmişse hata iş öğelerinin otomatik olarak çözümlenmesi gerektiğ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 DEFAULTREASON REASON bir alan kuralı 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 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 bir 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 State 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 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ğ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>

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.