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.gitRemove remote branch
git push origin --delete feature/develop_release feature/master_for_releaseClean branch cache
git remote prune origin
git fetch --prunereference: 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 -fd3 用 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.configGit log search keyword
git log -g --grep="vsts28270"
Section 1. 如果重來, 我會這樣導入持續測試
什麼是持續測試?
持續測試是一個過程, 它將自動化測試放進軟體開發之中, 不斷的反覆進行, 以期儘早的業務風險的回饋。ref: 持续测试与自动化测试的区别是什么？
Automation Test 不是敏捷導入所要做的第一件事
在產品設計時就提供實例化規格
Why?
How?
讓 User 做測試
這一點是有趣的地方,提到利用金絲雀部署 -> Monitor (建立指標) -> Feedback --> Fix用原生的測試框架
測試人員的技術與 Develop 重疊, 彼此能有正向的聯結 (減少 solio)ATDD
對 Develop Team 的技術及能力要求很高, 不容易做到目標先不對準 Live Documents, 而是做好 acceptance criteria
Git Branch Flow
Git Flow 的問題是 Long-lived branches, 不利整合用 tunk branch 可以強迫團隊合併持續整合
導入樂高建構法, 寫完什麼就 commit 什麼, Feature 如果不要發, 就藏在 debug mode 裡
持續測試的週期
<–需求–|--產品設計–|--開發–|--測試–|--監控結果–|--維護–>Section 2. 從工程角度, 挖出產品風險
讓團隊了解指標的意義
- 先視覺化業務的結果 (report, dashboard 像1111一樣)
- 建立指標 (了解 dashboard 上的數字高低對系統的意義是什麼)
平常時不監控, 事情發生就無感做這些事的過程:
不要指望明星球員
- 明星球員離職對團隊影響大
- 明星球員在場, 團隊會依賴明星球員, 團隊不會成長
我想的是: 如果讓每個人都是備選的明星球員, 隨時都能補位?吃狗食
- 自己的東西自己測試
QA 角色定位是指出測試不足之處, 不是幫 Developer 寫測試 code流程導入的建議
Section 3. Agile UX
設計帶來改變
設計用來協助解決 Fuzzy Problem ===> Innovative Solutions1. Mind the Gap 全區思考, 留意間隙
有意識的留意 Gap
MVP 也要是 end to end 的體驗如何消除 Gap?
辦 Workshop 的方式
- 為什麼辦?
- 對象是誰?
- 辦了之後, 可能會有什麼問題?
辦 Workshop 要成功的關鍵在前期規劃2. Run with Brian 謀定而後動, 知止而有得
3. Close the Loop 反覆打磨, 止於至善
幾個推薦的 Process or User Group