azure-devops


[05][讓團隊彼此知道程式碼走向]如何强制走Pull Request?以及設定符合規則才能合並分支

[05][讓團隊彼此知道程式碼走向]如何强制走Pull Request以及設定符合規則才能合並分支.jpg
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/、https://www.freepik.com/free-photo/magnifying-glass-stock-market-graph-paper_3095564.htm

在上一篇([04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程)介紹完了整個Code Review的過程,從最一開始的需求,到修改好之後,透過Pull Request做Code Review然後把修改合並回主線。

基本上所有的功能基本都會使用了,但是還有一個很大的問題:如果開發者不走Pull Request的話一切不都完了?

這一篇將來看一下,如何强制要求一定要走Pull Request,並且一些設定讓Pull Request一定要有符合某些條件才可以結束。


[04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程

[04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程.jpg
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/、https://www.freepik.com/free-photo/magnifying-glass-stock-market-graph-paper_3095564.htm

在上一篇([03]Azure DevOps的Pull Request提供了什麽功能?)瞭解了整個Azure DevOps的Pull Request功能之後,接下來就是看看在實際上如果整個串起來是什麽感覺。

這篇將從做一開始的需求,到最後整個功能確認修改好並且合併回主要分支。

這一篇也希望可以看到Azure DevOps這種一整套整合好的工具的好處。


[03][讓團隊彼此知道程式碼走向]Azure DevOps的Pull Request提供了什麽功能?

[03][讓團隊彼此知道程式碼走向]Azure DevOps的Pull Request提供了什麽功能?.jpg
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/、https://www.freepik.com/free-photo/magnifying-glass-stock-market-graph-paper_3095564.htm

在上一篇(何爲Pull Request並且如何建立 - 以Azure DevOps爲例)介紹了如何透過建立branch來把修改獨立出來,並且在修改完成之後透過建立Pull Request的方式建立出可以Code Review的一個請求。

這一篇將來看看Azure DevOps裡面的Pull Request包含了那些功能。


[02][讓團隊彼此知道程式碼走向]何爲Pull Request並且如何建立 - 以Azure DevOps爲例

[02][讓團隊彼此知道程式碼走向]何爲Pull Request並且如何建立 - 以Azure DevOps爲例.jpg
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/、https://www.freepik.com/free-photo/magnifying-glass-stock-market-graph-paper_3095564.htm

在上一篇([01]淺談Code Review的好處及意義篇 - 讓團隊彼此知道程式碼走向)瞭解了什麽是Code Review以及爲什麽可能會想要做Code Review之後。

下一個問題就是,如果真的想開始實行該怎麽做呢?

這一篇來介紹一下Pull Request的概念,以及如何協助做Code Review。


[Azure DevOps]如何設定Pull Request的預設文字模板(template)

[Azure DevOps]如何設定Pull Request的預設文字模板(template).jpg
圖片來源:https://pixabay.com/en/despair-alone-being-alone-archetype-513528/

Pull Request是一個非常好的Code Review方式,也是當初Github讓git火紅起來的其中一個原因之一。

在建立Pull Request的時候,一般會有一段訊息可以輸入,這個訊息主要描述了這一次Pull Request的一個主要目的。

但是,當團隊合作開發的時候,很有可能A工程師會輸入一種格式的内容,而B工程師又是另外一種。或者有時候有些條件需要符合才應該發起Pull Request,但是工程師忘記了,造成Reviewer需要花時間最後才發現根本最基本的條件都沒達到。

有沒有什麽方式可以提醒工程師在Pull Request發起的訊息要打好,並且該檢查的東西都要檢查過了呢?

這一篇,來看看在Azure DevOps裡面,如何透過建立template(範本)達到這個需求。


[VSTS]如何調整Visual Studio Team Service的區域(Region)

image
圖片來源:https://pixabay.com/en/key-tag-security-label-symbol-2114047/

Visual Studio Team Services (VSTS) 可以簡單理解成為雲端版的Team Foundation Server (TFS),而且微軟很佛心的讓5人以下團隊免費使用。

在建立VSTS的時候,有個選項是VSTS的資料要放在哪個區域(Region)。早期的時候,只有在美國,現在的話在東亞(East Asia)也有辦法建立了。

不過如果是早期建立在美國的VSTS是否能夠移動到East Asia呢?這篇將會介紹如何透過寫VSTS的support ticket來達到這個轉換。


[從.Net工程師的角度來看DevOps 21]Build階段的總結和重構 - Build Server介紹

image圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

在上篇[iThome第8屆鐵人賽 20]靜態程式碼分析之程式碼風格 - Stylecop介紹完了如何整合stylecop之後,build階段也差不多到了一個階段。

在這個階段裡面,從最基本的編譯、到執行單元測試、到整合程式碼測試的涵蓋率最後整合Code Analysis和stylecop,整個build基本要做的都做了,因此我們要開始進入如何把這個建制整合到builder server來達到CI的效果

在這篇,將會談到:

  1. 在一次重構和調整script - 以符合上build server執行的時候比較沒有問題
  2. 對build server做個簡單的介紹

[回顧][活動][Study4]20170624-大家應該都要會的工具 git - 從放棄到會用

在2017/06/24的時候非常有榮幸和大家在Study4的6月場次裡面介紹了git。

我對於大家聽完的感想其實非常有興趣,因此做了一個問卷請大家幫忙填寫。

大家都那麼認真幫我做了填寫,我當然也要認真的把大家的建議納入進去 - 因此這篇我將會對我看問卷的結果和自己時候思考到的問題總結一下,作為未來修正的參考。

前情提要

活動相關資訊
Study4 6月活動
簡報主要內容
版控歷史介紹、gui和powershell操作、Visual Studio Team Service介紹、Visual Studio Code搭配呼叫
相關投影片