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

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018-TFS 2013

Önemli

Bu makale, şirket içi XML işlem modelleriyle ilgili proje özelleştirmesi için geçerlidir. İşlem modellerine genel bakış için bkz. iş izleme deneyiminizi özelleştirme.

İş ve takım işlemlerinizi desteklemek için bir iş öğesi türü (WıT) iş akışını değiştirebilirsiniz. Yazılım geliştirmeyi desteklemek için tüm iş türlerinin (gereksinimler, görevler, kod kusurları) izlenmesini destekler.

İş akışı, takım üyelerinin gerçekleştireceği çalışmanın mantıksal ilerlemesini ve gerilemesini belirler. Ayrıca durum ve neden alanları için açılan menülerde görünen değerleri de belirtir. Varsayılan işlem şablonlarında desteklenen varsayılan iş akışı durumlarına genel bakış için bkz. Işlem seçme.

Ürün biriktirme listesi öğesi (Scrum işlem şablonu) için iş akışı

Ürün biriktirme listesi öğe iş akışı, Scrum işlemi

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 isterseniz, aşağıdaki konulardan birine bakın: iş öğeleri ekleme, çalışma durumunu güncelleştirme, Kanban panosu, sürmekte olan işleri izlemeveya görev panosu, görev durumunu güncelleştirme. Ayrıca , birçok çalışma öğesi Için durumun toplu bir güncelleştirmesinide yapabilirsiniz.

Derleme işlem hattı iş akışları hakkında daha fazla bilgi için bkz. CI/CD ile çalışmaya başlama.

WıT için XML tanımını güncelleştirme

WıT özelleştirmesi ' nı yeni kullanıyorsanız aşağıdakilere göz önünde olabilirsiniz:

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

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

  2. Yeni iş akışı durumlarını meta durumları eşlenecek şekilde işlem yapılandırmasını değiştirin.

    Çevik araç sayfasında görünen bir WıT için iş akışını değiştirdiğinizde bu ikinci adım gereklidir. Bu WTS, gereksinim ya da görev kategorilerine aittir. Durum kategorileri hakkında daha fazla bilgi için bkz. Iş akışı durumları ve durum kategorileri.

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

İş akışını öncelikle durumları ve bunlar arasındaki geçerli geçişleri tanımlayarak tanımlarsınız. WORKFLOWWIT tanımının bölümü, bir takım üyesi bir iş öğesinin durumunu değiştirdiğinde gerçekleştirilecek olan geçerli durumları, geçişleri, geçişleri nedenlerini ve isteğe bağlı eylemleri belirtir.

Genel olarak, her durumu bir takım ü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ında geçerli ilerlemeleri ve gerilemeleri tanımlar. Nedenler, bir ekip üyesinin bir çalışma öğesini bir durumdan diğerine değiştirmesinin neden olduğunu ve eylemlerin iş akışındaki bir noktada bir iş öğesi geçişinin otomatikleştirilmesini destekledikleri tespit.

Örneğin, bir sınayıcı varsayılan çevik işleme dayalı yeni bir hata açtığında durum Yeni olarak ayarlanır. Geliştirici, hatayı düzelttiğinde 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 düzeltildiolarak ayarlar. Onarım doğrulandıktan sonra, sınayıcı hatanın durumunu kapalı olarak değiştirir ve neden alanı doğrulandıolarak değişir. Sınayıcı, geliştiricinin hatayı düzeltmediklerini tespit ederseniz, sınayıcı hatanın durumunu etkin olarak değiştirebilir ve nedeni düzeltilmedi veya test başarısızolarak belirtir.

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

  • STATEBir iş öğesi üzerinde belirli bir eylemi alacak her bir takım üyesi rolü için benzersiz bir durum tanımlamak üzere öğesini kullanın. Ne kadar fazla durum tanımlacağınızı, daha fazla geçiş tanımlamanız gerekir. Durumları tanımladığınız sıra ne olursa olsun, durum alanının açılan menüsünde alfasayısal sırada listelenir.

    Web portalındaki biriktirme listesi veya pano sayfalarında görüntülenen iş öğesi türüne bir durum eklerseniz, durumu bir durum kategorisiyle de eşlemeniz gerekir. Daha fazla bilgi edinmek için Iş akışı durumlarını ve durum kategorilerinigözden geçirin.

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

    En azından, her durum için bir geçiş ve null durumundan başlangıç durumuna geçiş tanımlamanız gerekir.

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

    Bir takım ü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 olan durumları belirtebilir. Ayrıca, bir ACTION alt öğesi olan bir öğesi, TRANSITION bir iş öğesinin durumunu değiştirebilir.

  • Her geçiş için, öğesini kullanarak varsayılan bir neden tanımlarsınız DEFAULTREASON . Öğesini kullanarak istediğiniz kadar isteğe bağlı neden belirleyebilirsiniz REASON . Bu değerler, neden alanının açılan menüsünde görünür.

  • Çalışma öğesi durumu değiştirdiğinde, ne zaman geçiş yaptığında veya bir Kullanıcı belirli bir neden seçtiğinde uygulanacak kuralları belirtebilirsiniz. Bu kuralların birçoğu, tanım altındaki bölümünde alanları tanımlarken uygulayabileceğiniz koşullu kuralları tamamlar FIELDSWORKITEMTYPE . Daha fazla bilgi için, bu konunun ilerleyen kısımlarında yer alan iş 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ıdır.

    Çalışma öğesi formu veya sorgu Düzenleyicisi içindeki durum ve neden alanlarının açılır menüleri, WORKFLOW iş öğesi türünün bölümünde atanan değerleri görüntüler.

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

Aşağıdaki kod örneğinde, WORKFLOW çevik işlem şablonu Için hata WIT tanımı gösterilmektedir. Bu örnek üç durum ve beş geçişi tanımlar. STATEÖğeler, etkin, çözümlenmiş ve kapalı durumlarını belirtir. İlerleme ve regresyon geçişleri için tüm olası birleşimler, bunlardan biri hariç olmak üzere üç durum için tanımlanır. Closed öğesinden çözümlenme geçiş tanımlanmadı. Bu nedenle, iş öğesi kapalıysa takım üyeleri bu türdeki bir iş öğesini çözemez.

Bu örnek,,, ve için tüm öğeleri listeetmez DEFAULTREASONREASONACTIONFIELD .

Örnek Iş akışı durum diyagramı — Çevik hata WıT

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 mevcut olmasını istediğiniz farklı mantıksal durumların sayısına göre belirlersiniz. Ayrıca, farklı takım üyeleri farklı eylemler gerçekleştirse, bir üye rolüne göre bir durum tanımlamayı düşünebilirsiniz. Her durum, bir takım üyesinin bir sonraki duruma taşımak için iş öğesi üzerinde gerçekleştirmesi gereken bir eyleme karşılık gelir. Her durum için, belirli eylemleri ve bu eylemleri gerçekleştirmesine izin verilen takım üyelerini tanımlamanız gerekir.

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

Durum Geçerli Kullanıcı Gerçekleştirilecek eylem
Önerilen Proje yöneticisi Herkes bir özellik iş öğesi oluşturabilir. Ancak, yalnızca proje yöneticileri iş öğesini onaylayabilir veya onaylayabilirler. Bir proje yöneticisi bir özelliği onayladığında, Proje Yöneticisi iş öğesinin durumunu etkin olarak değiştirir; Aksi takdirde, bir takım üyesi bunu kapatır.
Etkin Geliştirme lideri Geliştirme lideri, özelliğin geliştirilmesini aşırı görür. Özellik tamamlandığında, geliştirme lideri özellik iş öğesinin durumunu gözden geçirme olarak değiştirir.
Gözden geçirme Proje yöneticisi Proje Yöneticisi ekibin uyguladığı özelliği inceler ve uygulamanın tatmin edici olması durumunda iş öğesinin durumunu kapalı olarak değiştirir.
Kapatıldı Proje yöneticisi Kapatılan iş öğelerinde başka bir eylemin gerçekleşmesi beklenmez. Bu öğeler arşiv ve raporlama amaçları için veritabanında kalır.

Not

Tüm durumlar, belirttiğiniz dizi ne olursa olsun, belirli bir türün iş öğesi için form üzerindeki listede alfabetik sırada görünür.

Geçişleri tanımlama

Geçerli durum ilerlemeleri ve gerilemeleri tanımlarsanız, hangi takım üyelerinin bir iş öğesini değiştirebileceği ve bu durumları kontrol edersiniz. Bir durumdan başka bir duruma geçiş tanımlamadıysanız, takım üyeleri belirli bir durumdaki bir iş öğesini belirli bir durumdan başka bir özel duruma değiştiremez.

Aşağıdaki tablo, bu konuda daha önce açıklanan dört durumun her biri için geçerli geçişleri, her birinin varsayılan nedeni tanımlar.

Durum Duruma geçiş Varsayılan neden
Önerilen Etkin (ilerleme) Geliştirme için onaylandı
Kapalı (ilerleme) Onaylanmamış
Etkin İnceleme (ilerleme) Kabul ölçütleri karşılandı
Gözden geçirme Kapalı (ilerleme) Özellik Tamam
Etkin (gerileme) Gereksinimleri karşılamıyor
Kapatıldı Önerilen (gerileme) Onay için yeniden dikkate al
Etkin (gerileme) Hatalı olarak kapatıldı

Öğesinin for ve Notfor ö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 kullanamaz.

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

Nedenleri belirtin

Bir ekip üyesi durum alanını değiştirdiğinde, bu kullanıcı o geçişin varsayılan nedenini koruyabilir veya ek seçenekler tanımlarsanız farklı bir neden belirtebilir. DEFAULTREASONÖğesini ve yalnızca bir varsayılan neden belirtmek için öğesini kullanmanız gerekir. Yalnızca ekibin verileri izlemesine veya raporlarsa ek nedenler belirtmeniz gerekir.

Örneğin, bir geliştirici bir hatayı çözümlerse aşağıdaki nedenlerden birini belirtebilir: sabit (varsayılan), ertelenmiş, yinelenen, tasarlanan, yeniden oluşturulamaz veya kullanılmıyor olabilir. Her nedenden dolayı, test edicinin hatayla ilgili olarak gerçekleştirmesi için belirli bir eylem belirtir.

Not

Tüm nedenler, öğeleri belirttiğiniz diziye bakılmaksızın belirli bir türdeki iş öğeleri için çalışma formundaki listede alfabetik sırada görünür REASON .

Aşağıdaki örnek, bir takımın bir üyesinin bir hatayı çözebileceği nedenleri tanımlayan öğeleri gösterir:

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

Genel olarak, takım üyeleri, durum alanı için farklı bir değer belirterek ve sonra iş öğesini kaydederek iş öğesinin durumunu değiştirir. Ancak, ACTION bir iş öğesinin durumunu otomatik olarak değiştiren bir öğe tanımlayabilirsiniz, bu da geçiş meydana gelir. Aşağıdaki örnekte gösterildiği gibi, bir geliştiricinin sürüm denetimine denetlediği dosyalarla ilişkilendirildiklerinde hata iş öğelerinin otomatik olarak çözülmesi gerektiğini belirtebilirsiniz:

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

ACTIONMicrosoft Visual Studio uygulama yaşam döngüsü yönetiminde veya Visual Studio uygulama yaşam döngüsü yönetimi dışında (ö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. Daha fazla bilgi için bkz. eylem.

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

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

  • STATEKuralın, bu durumu girmeye yönelik tüm geçişler ve nedenler için uygulanmasını istediğiniz zaman bir alan kuralı atayın.

  • TRANSITIONKuralın bu geçiş için uygulanmasını istediğinizde ve bu geçişi yapmak için tüm nedenlerden bir alan kuralı atayın.

  • DEFAULTREASONREASON Kuralların yalnızca belirli bir nedenle uygulanmasını istiyorsanız, veya altına bir alan kuralı atayın.

    Bir alan her zaman aynı değeri içeriyorsa, kuralı FIELD Bu alanı tanımlayan öğe 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 indirmeye çalışmanız gerekir. Eklediğiniz her bir koşullu kural ile, bir takım üyesi bir iş öğesini kaydettiğinde oluşan 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 kuralların bazıları gösterilmektedir.

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

Bir iş öğesi için 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ı adına ayarlanır. bu kullanıcının Team Foundation Server geçerli kullanıcılar grubunun bir üyesi olması gerekir. Etkin tarih alanının değeri de otomatik olarak ayarlanır. Aşağıdaki örnek, bu kuralı zorlayan öğeleri gösterir:

<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 bir alanın değerini temizle

Bir iş öğesi için durum alanının değeri etkin olarak ayarlandığında ve iş öğesi kaydedildiğinde, kapatılan tarih ve kapatan alanları otomatik olarak null olarak ayarlanır ve Aşağıdaki örnekte gösterildiği gibi öğesini kullanırsanız, salt okunurdur.

<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 bir alan tanımlayın

Bir iş öğesi için durum alanının değeri çözümlenme değiştiğinde ve iş öğesi kaydedildiğinde, Çözümlenmiş neden alanının değeri kullanıcının neden alanında belirttiği değere ayarlanır. Aşağıdaki örnek, bu kuralı zorlayan öğeleri gösterir:

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

Araç desteği

Visual Studio marketi 'nden durum modeli görselleştirme uzantısını yükleyerek, kullanıcılarınızı iş akışını görselleştirmek üzere destekleyebilirsiniz.