Aracılığıyla paylaş


İş öğ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ş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 İş Listesi Öğesi İş Akışı (Scrum süreç ş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 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ş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 referansına başvurmanız gerekir.
  • İş öğ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. 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, bir test uzmanı varsayılan Çevik süreç temel alınarak 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:

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

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>

Durumların 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 / 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

Geçerli durum ilerlemelerini ve gerilemelerini tanımlarsanız, ekip üyelerinin iş öğesini hangi durumlara ve durumlardan değiştirebileceğini 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 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.

  • 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, 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 değeri Etkin olarak ayarlandığında ve iş öğesi kaydedildiğinde, EMPTY öğesini kullanırsanız, Kapalı Tarih ve Kapanış Yapan alanları otomatik olarak null olarak ayarlanır ve salt okunur hale getirilir. Bu durum, aşağıdaki örnekte gösterilmektedir.

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