2018/12/07

常用 Git Command

### Initialization ``` git clone git@bitbucket.org:jessewth/xxxxx.deployment.git git flow init -f -d git remote add upstream git@bitbucket.org:xxxxxi/nineyi.deployment.git ``` ### Remove remote branch ``` git push origin --delete feature/develop_release feature/master_for_release ``` ### Clean branch cache ``` git remote prune origin git fetch --prune ``` reference: [Git: Remove information on branches that were deleted on origin](https://makandracards.com/makandra/6739-git-remove-information-on-branches-that-were-deleted-on-origin) ### Git tag https://git-scm.com/book/en/v2/Git-Basics-Tagging ### 還原到未修改前的狀態 ``` git reset --hard ``` ### 還原到未修改前的狀態及刪除未 commit 的新檔 ``` git clean -fd ``` ##3 用 command line 看 git log ``` git log --oneline --decorate --all --graph ``` 為了方便使用, 把上述 command 加入 alias, 命名為 git tree, 下次要用的時候, 直接打 git tree 即可 ``` git config --global alias.tree "log --oneline --decorate --all --graph" ``` ### 回復單一個檔案的變更 ``` git checkout HEAD -- ../../ConnectionStrings.config ``` ### Git log search keyword ``` git log -g --grep="vsts28270" ```

2018/12/06

Agile Tour Taipei - 2018 心得

Section 1. 如果重來, 我會這樣導入持續測試

什麼是持續測試?

持續測試是一個過程, 它將自動化測試放進軟體開發之中, 不斷的反覆進行, 以期儘早的業務風險的回饋。
ref: 持续测试与自动化测试的区别是什么?

Automation Test 不是敏捷導入所要做的第一件事

  • 應該先改 Test Flow
  • 縮短回饋時間 Lead time, cycle time
  • 了解流程全貎

在產品設計時就提供實例化規格

Why?

  • 因為每個人對文字的理解力不同
  • 幫助每個人了解求

How?

  • Example for Spec.
  • PM/PO/Team 的訓練

讓 User 做測試

這一點是有趣的地方,提到利用金絲雀部署 -> Monitor (建立指標) -> Feedback --> Fix
  • 與其卡在 QA 出不去, 不如讓使用者幫忙測試
  • 金絲雀部署, 5% 的 user 也比整個 QA Team 還多
  • 沒人用的功能, 錯了也沒人知道

用原生的測試框架

測試人員的技術與 Develop 重疊, 彼此能有正向的聯結 (減少 solio)


ATDD

對 Develop Team 的技術及能力要求很高, 不容易做到
目標先不對準 Live Documents, 而是做好 acceptance criteria


Git Branch Flow

Git Flow 的問題是 Long-lived branches, 不利整合
用 tunk branch 可以強迫團隊合併持續整合
導入樂高建構法, 寫完什麼就 commit 什麼, Feature 如果不要發, 就藏在 debug mode 裡

持續測試的週期

<–需求–|--產品設計–|--開發–|--測試–|--監控結果–|--維護–>
  1. 需求階段: 測試人員參與討論
  2. 產品設計階段: 一起寫 user story, 用 example spec.
  3. 開發階段: 與 Developer 用共同語言的測試框架
  4. 測試階段: 自動化測試
  5. 監控結果: 建立監控指標, 每次發佈都有指標可以比較
  6. 維護階段: 建立回饋機制

Section 2. 從工程角度, 挖出產品風險

讓團隊了解指標的意義

  • 先視覺化業務的結果 (report, dashboard 像1111一樣)
  • 建立指標 (了解 dashboard 上的數字高低對系統的意義是什麼)
平常時不監控, 事情發生就無感
做這些事的過程:
經驗流程化 -> 流程工具化 -> 主動發現問題

不要指望明星球員

  • 明星球員離職對團隊影響大
  • 明星球員在場, 團隊會依賴明星球員, 團隊不會成長
我想的是: 如果讓每個人都是備選的明星球員, 隨時都能補位?

吃狗食

  • 自己的東西自己測試
QA 角色定位是指出測試不足之處, 不是幫 Developer 寫測試 code


流程導入的建議

  • 了解大家不用的原因
  • 把門檻降低
  • 大家願意之後, 刻意練習
  • 同步大家的水平, 減少不必要的紛爭

Section 3. Agile UX

設計帶來改變

設計用來協助解決 Fuzzy Problem ===> Innovative Solutions

1. Mind the Gap 全區思考, 留意間隙

有意識的留意 Gap

  • Business vs User
  • MVP vs Holistic UX
MVP 也要是 end to end 的體驗
如何消除 Gap?
  • 同理心之旅
  • 溝通要二方都被尊重, 在對意見投票時, 留給 Stakeholder 較大的決策權, 避免被霸凌

辦 Workshop 的方式

  • 為什麼辦?
  • 對象是誰?
  • 辦了之後, 可能會有什麼問題?
辦 Workshop 要成功的關鍵在前期規劃

2. Run with Brian 謀定而後動, 知止而有得

  • Discover & Define (Sprint 0, 用來探索)
  • Design & Deliver, 設計與開發像麻花捲, 前後 sprint 滾

3. Close the Loop 反覆打磨, 止於至善

  • 持續得到回饋(讓外部 user 持續來用)
  • Real retro

幾個推薦的 Process or User Group

T-SQL 語法風格