原文地址：https://www.zhihu.com/question/54626462
管理工具：
1.需求管理工具
confluence 是一個基於java企業知識平臺，基本上是一個企業博客，他有一些工作流管理功能，也支持很多插件（如UML、思維等等），容易定製。
2.基於敏捷管理的sprint、backlog、開發task、bug管理工具
jira 是一個基於java的issue(問題、事項)管理器，類似的產品有禪道，github也有簡單的issue管理，支持很多插件，而且可定製。
3.代碼管理
gitlab 是一個類似於github的東西，它是採用ruby開發的，支持自己的一套智能提交，並且非常開放，易於集成。
4.部署打包
jenkins 是一個java實現的持續集成工具，圖標是一個紳士小老頭很搞笑，在我這邊一般它會工作在觸發後執行打包腳本，進行自動化的集成部署，完成後會發送郵件提示，通知結果。後期我這邊將它和nexus進行了整合，改變了一些使用方法，但是大致還是這樣子。雖然這個是java寫的，但是完全可以用作其他語言的持續部署，它很神奇，很省心，也很易用。
費用？
jira & confluence & 插件
也應該看到了，我這邊用的是正版，不推薦D版，請支持正版。
官方有費用的介紹，國內有代理，可以開發票是可以比較方便走賬的，價格相對而言還是比較可觀。
最低有10人10美元授權，其實巧妙分組使用此授權可以在更多人數的團隊中使用(就是說不是一套JIRA)，但記得其實人家授權協議中是不同意這樣子做的（其實我也沒仔細看）。
插件
插件大多支持試用一段時間，大可以裝上試用下，感覺好了再付費。
google可以搜到很多人的評價，在 http://stackoverflow.com 和 Hot Questions - Stack Exchange 中也有很多評論可以參考，慢慢搜索就行了。
對硬件的要求？
內存：
在實際使用中發現，jira 和 confluence 很吃內存，分配小內存使用起來效果並不好，我在內部服務器上配置了48G內存，給亂七八糟的服務去使用，使用起來體驗還可以。
處理器：
對於cpu等吃的並不厲害。
硬盤：
對於硬盤 iops 相對於內存次要敏感，我這邊是配置了兩張 ssd 做的 raid1（mdadm做的），使用中感覺還可以。
網絡：
延時還是要低些吧，你放到美國的vps上300多ms的延時估計用起來是不會開心的。
在實踐中需要應用的其他工具或產品？
linux服務器 應該不是必須的？據說可以用windows？我沒考證過，所以寫在這裏吧。
tomcat 這是apache下的開源項目，是一個 JSP/Servlet 容器（就是跑java網站用的服務端），另外還有jboss等，但是我們用不到ejb，所以tomcat是個好選擇。
nginx web服務端，也可以作爲反向代理（實際上用作反向代理比較多）
postgresql 一款學院派風格的關係型數據庫（雖然也支持nosql），性能很不錯，使用起來坑也比較少，對於一些特性他比mysql兼容的好，我這邊大量在使用。這個不是必須的，用mysql，sqlserver（這個我沒試過）是可以替代的。雖然他支持nosql數據庫，但還是不要用的比較好。
雙向證書驗證 一般的https是單向的，即服務端裝證書，客戶端驗證，而雙向證書顧名思義就是雙向的，客戶端也要有，服務端會驗證客戶端的證書，沒證書，訪問不了。
我這邊吧服務都放在了公網，雖說代碼本身是不怕同僚離職時帶走，但是考慮到其他方面這顯然不太安全，所以採用了雙向認證的方案。
在實施中吧個人證書與自建CA的根證書分發給同僚，進行安裝後即可訪問，但是沒有證書訪問頁面就會404，製造出沒有這個頁面的假象。
自建CA 因爲採用了公網部署雙向證書驗證的方案，口袋裏又沒有錢都去用正規CA的證書，所以這個基本不可少。
可選技術？
docker 這個當下非常火，不必多說了。在實際使用中我嘗試過吧這幾個項目部署到docker裏，但是就體驗來說效果不好。在實際使用中主要是吧 docker 來結合 spring cloud 來使用。
nexus 一個開放的自建maven，可以代理中央服務器，也可以上傳內部的包讓團隊成員共享與使用，做java方面的開發這個可謂是不可不用。
ss-local 這個我不展開了，畢竟你懂的。這是一個神奇的梯子工具的客戶端，我在內部服務器（即跑這些應用的服務器，而不是內網中的服務器）中進行了部署，連接到東京的linode，來給nexus加速。在安裝這一堆亂七八糟的過程中使用此神器可以大大加速下載速度，如果你在國外應該用不到這個。
privoxy 一個代理服務器，ss-local提供的是一個socks5代理，但是畢竟用socks5很多地方不方便，比如終端下並不能簡單的使用，而很多應用也只支持使用http代理，所以就用它來進行socks 到 http 的轉換。
jira git 插件 一個可以和git庫進行集成的插件，對雙向證書支持不好，只能在nginx給此插件開小竈不走雙向認證。
jira gantt-charts 插件 一個jira展示甘特圖的插件，體驗很不錯，排版容易混亂，但並不影響使用。
confluence http://draw.io 插件 畫圖用的，基本上常見的圖都支持，但是體驗一般，可以安裝其他插件進行優勢互補。
jira 和 confluence 中文漢化包 顧名思義，對於像是我這種只有小學英語水平的人尤爲重要。
zsh 一個神奇的shell，用他來增加終端使用git的體驗
oh-my-zsh 顧名思義，用zsh幾乎必備
如何使用這一堆亂七八糟？
至於集成與賬號創建等我會在配置安裝章節進行闡述，在此只提供一個用例。
感覺碼字好麻煩，只寫基於默認的情況下一種符合大多數情況的案例吧，供大家參考：
項目定下來後首先用 jira 建立項目，首推：
這個使用起來效果是很不錯的。另外你也可以很方便的建立自己的類型，讓他符合自己的需求，但在此不展開了。
然後進行必要的項目配置，這裏的甘特圖選項請設置好，要不甘特圖有些功能會有問題。
創建版本
然後跑到 confluence 建立庫，推薦選擇這個：
同理也可以建立自己的來用（不復雜，摸索下即可）。選好項目關聯好，並創建:
這時候一般會開個會議大家考慮下戰略、任務怎麼分配以及怎麼下手去幹，這時候創建一個會議記錄。
對會議內容進行記錄。
在參會內容中對參與人員進行'@'即可：
其他按照模板項進行填充，其中行動項請務必填寫，這個很實用。
這樣子保存後參會人就會收到提示，如果配置了郵箱提醒還會看到郵件。
然後掃中展示的行動項，建立jira任務：
此時會看到已經關聯。
jira中也已經有了
分配好經辦人，新建一個sprint並且把任務拖進去將經辦人分配好，在此例中分配給我了我自己。如果要拆分子任務也請此時進行。
然後開始sprint，這時在甘特圖中已經可以看到了，在active sprints中也可以拖動任務了。
任務拖動到其他階段後，confluence就會更新，
大家都能看到做到哪裏以及做的怎麼樣了。
在這裏因爲要求做需求，創建一個產品要求在裏面。左側 產品要求->Create product requirement 把需要的項目都填好。
問題過濾器中這裏就直接獲得所有沒結束的，實際使用中可以按需要獲得，比如獲得屬於這個需求的，等等。
我採用的是列表展示20條，這會導致排版不好看，但是實用些，如果感覺不舒服可以換形式，或者減少展現字段。
剩下的按照模板填寫。
保存後就會看到調用的問題
一個比較可用的方案是自定義模板，但是在此就不展開了，有需要可以查看官方教程。決策日誌，和回顧等大同小異我不再贅述。
開發過程中，一定要使用jira的智能提交，這非常好用。
在gitlab中創建版本庫，並且添加必要的README等等，另外就是配置好 Project services 集成好jira
點擊 test 試試看是不是配置正確。點擊issues 來試試是否能跳到展現頁面。
在gitlab裏給這個項目加入一個JIRA的新成員
去jira git 插件中查看webhooks 
吧webhooks給設定好（在你的jira中git插件裏面查看，就上面那個）
保存測試成功了纔可以。回到JIRA去更新下GIT插件的索引
把項目克隆到本地然後測試一下智能提交，確定ok。
爲了方便演示智能提交加上這個項目還沒README，所以就拿加入README來演示，首先在JIRA創建一個任務並且開始做這個任務。
然後我們來做這個任務（這裏你也看到我用了zsh和oh-my-zsh，其實是可以用ga gp 之類的，你也可以用用看）這裏很顯然我配置過key，沒有配置請先配置。
（平時我使用了ssh的~/.ssh/config 配置文件來設定服務器的，此處可以直接使用常見的git形式，不必像這裏一樣去ssh://，此處僅爲演示，實際使用推薦還是採取ssh config配置文件+遠程地址無關的形式比較好，因爲這樣子換域名換端口，同僚可以不必一個一個去修改git的config，而是改一個 ssh config 即可）這時如果你在另外一個屏幕上開着JIRA的話應該已經自動移到Done裏面了（並不需要刷新）
甘特什麼的也已經更新了，要是關注過問題的人也會收到提醒。這種神奇的效果就是剛剛那句 commit 命令，這個就叫做智能提交，gitlab-shell會去調用gitlab，gitlab又去通過剛剛設定的web鉤子去拽一下jira，jira去刷新庫（以下不再贅述運行過程，不必要的感覺），這個實際使用中體驗還是不錯的。這裏用的這個是改變當前狀態的。格式是：
git commit -m "JIRA的任務KEY #目的狀態 解釋"
如果你有多個任務可以用空格間隔重複前半部分，不需要提交多次。
對於智能提交jira官方是有詳盡說明的，我放連接，需要的可以去慢慢研究，一般在使用中我是會弄個環境變量或者腳本來方便提交 issue key ，畢竟有的項目會把KEY搞得很長，輸入起來並不是很方便，有的同僚是採取IDEA中設定ISSUE的方式，這些都是比較好的辦法。
Atlassian Documentation
（如果沒有設定過本地 git 的 config 請按照gitlab下面的步驟來做一下，不去設定的話會發現提交後不會關聯到對應用戶，它是按照郵箱進行的索引，所以郵箱是尤爲重要的）
（另外扯一句題外話，我曾經見過一些同行，不知道代碼潔癖還是有要求怎麼的，git提交錯了，push了，消尖了腦袋去改git的提交，莫非跟績效掛鉤？在我看來這是大可不必的，提交錯了重新提交一次即可，大可不必在這裏鑽牛角尖，要不天天改提交，哪天手抖輸敲錯了就心塞了反而麻煩。至於代碼審覈也請不要基於提交爲單位展開，要不真會逼人去改提交，而且代碼審覈這種事最好是上下文都要看到纔好，不知道上下文的話突然插進來不要談審覈，哪裏是那裏都不知道。）