PTT職涯區 / Soft_Job (軟體人)

[請益] 解決公司過多測試環境的問題消失

看板Soft_Job (軟體人)作者時間9年前 (2016/09/04 13:15), 9年前編輯推噓10(10推 0噓 59→)
留言69則, 11人參與, 最新討論串1/2 (看更多)
新進的公司，有一最重要的系統，重要程度是只要掛掉，當天全公司就無法運作。大家 就可以直接休息了。 有2個人及廠商維護。 難作的需求由廠商寫，簡單需求就有公司2個維護者寫。 這公司有點怪，可能會有2個人及廠商同時改一支程式或同時加db欄位或資料。 但上線與否是看user急不急和有沒有空測。 所以先提出來的需求例如9月1日某table加1欄位改好了！user沒空測。 後來10月1日另一個user提出的需求也要在同table同程式加欄位，但要先上線。 就要建2個測試環境給2個user用。 都是用8月31日正式環境再各別加上需求修改作出來的 但要是還沒測完11月1日又來一個需求，又要先測，又再用8月31日的環境建一個測試環境 給user。 所以公司有十幾個測試環境。 再加上廠商在自己公司開發，可能是5月1日的環境。 天啊！ 然後陸續測完要上線，又有mapping問題。 請問各位公司都怎樣處理此狀況的? -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.193.186.159 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1472966142.A.732.html ※ 編輯: O187 (123.193.186.159), 09/04/2016 13:20:47
→
09/04 13:22, , 1F
你知道版本控制系統是什麼嗎?
09/04 13:22, 1F
→
09/04 13:28, , 2F
版控能幫你解決2個需求在同畫面上欄位都新增在同一個位置及
09/04 13:28, 2F
→
09/04 13:28, , 3F
資料庫某筆資料同時被加1段字的問題嗎？
09/04 13:28, 3F
→
09/04 13:32, , 4F
這不當然的嗎...
09/04 13:32, 4F
→
09/04 13:34, , 5F
廠商應該有版控，但我們的控版是不能給廠商用，只能等他們開
09/04 13:34, 5F
→
09/04 13:34, , 6F
發完再幫他們放進來
09/04 13:34, 6F
→
09/04 13:36, , 7F
請問r大，哪個版控能作到? 那這版控是自動幫我算ui的位置，
09/04 13:36, 7F
→
09/04 13:36, , 8F
再去把重疊的往後還是往下移，並且不會跑到畫面外嗎?
09/04 13:36, 8F
→
09/04 13:42, , 9F
09/04 13:42, 9F
→
09/04 13:42, , 10F
歡迎加入 devops taiwan 應該會比較多同好。
09/04 13:42, 10F
→
09/04 13:47, , 11F
用了r大的版控，測試環境能否只用一個
09/04 13:47, 11F
→
09/04 14:03, , 12F
你知道ui的位置也是一段程式碼嗎? 合併出現衝突時不就能
09/04 14:03, 12F
→
09/04 14:03, , 13F
調整了嗎
09/04 14:03, 13F
→
09/04 14:04, , 14F
至於畫面的layout和測試環境的數量又沒關係
09/04 14:04, 14F
→
09/04 14:04, , 15F
版控會自動幫我調嗎？
09/04 14:04, 15F
→
09/04 14:07, , 16F
維護人員和廠商同時在db代碼表新加的代碼一樣時,版控能自動
09/04 14:07, 16F
→
09/04 14:07, , 17F
我重編代碼，連程式都自動改嗎？
09/04 14:07, 17F
→
09/04 14:15, , 18F
感覺你從沒用過版控？
09/04 14:15, 18F
→
09/04 14:16, , 19F
版控就是如果你們兩個改了同一個檔案，他會就你們兩邊的 c
09/04 14:16, 19F
→
09/04 14:16, , 20F
ode auto merge，如果有衝突，你這邊就必須修改到衝突結
09/04 14:16, 20F
→
09/04 14:16, , 21F
束才能再次上版控
09/04 14:16, 21F
→
09/04 14:19, , 22F
對方也一樣，我不知道你語言是什麼，但我寫 php 嚴禁同事
09/04 14:19, 22F
→
09/04 14:19, , 23F
直接手動修改 db schema，migrate 工具很多，檔案同步以
09/04 14:19, 23F
→
09/04 14:19, , 24F
後跑 migration db schema 自動統一，如果裡面有必要預設
09/04 14:19, 24F
→
09/04 14:19, , 25F
參數，在跑 seeder 上資料就好，每個人直接動 db 一定是悲
09/04 14:19, 25F
→
09/04 14:19, , 26F
劇
09/04 14:19, 26F
推
09/04 14:25, , 27F
1.沒有版控可以完美 merge，但好歹可以幫你分好 branch 吧
09/04 14:25, 27F
→
09/04 14:26, , 28F
如果用 git 廠商開發完也是發 pull request 進入主幹
09/04 14:26, 28F
→
09/04 14:26, , 29F
這樣至少清楚很多吧
09/04 14:26, 29F
→
09/04 14:27, , 30F
2.你需要的可能還包括自動測試？
09/04 14:27, 30F
→
09/04 14:57, , 31F
http://bit.ly/29AdVZV 有些書能看看哩
09/04 14:57, 31F
→
09/04 15:08, , 32F
解決掉提出問題的人 (就是你 XD (選我正解
09/04 15:08, 32F
→
09/04 15:24, , 33F
呃…目前用版控merge時遇到衝突的手動merge太花時間了，而且
09/04 15:24, 33F
→
09/04 15:24, , 34F
仍無法避免merge後重測的問題，還有維護過多測試環境的問題
09/04 15:24, 34F
→
09/04 15:26, , 35F
目前有用版控，但仍有原文那些問題時，各位都手動解決衝突
09/04 15:26, 35F
→
09/04 15:26, , 36F
的嗎？
09/04 15:26, 36F
→
09/04 15:27, , 37F
自動測試似乎無法測出畫面merge得很醜的問題
09/04 15:27, 37F
→
09/04 15:40, , 38F
感覺應該是ui db在測試上的問題，加上merge的時機不知道
09/04 15:40, 38F
→
09/04 15:40, , 39F
怎麼規劃...
09/04 15:40, 39F
→
09/04 15:44, , 40F
大家沒有user插件問題嗎？以前需求我都一件件作，所以merge
09/04 15:44, 40F
→
09/04 15:44, , 41F
工作在測試前就作好了，測也都一併測試
09/04 15:44, 41F
推
09/04 16:03, , 42F
user插件本來就要動併吧, 版控也不能處理改同一段code問題
09/04 16:03, 42F
→
09/04 16:03, , 43F
手動併版
09/04 16:03, 43F
→
09/04 16:03, , 44F
你的問題是政治問題不是工具問題
09/04 16:03, 44F
推
09/04 16:26, , 45F
1.你先讓自家維護的人用好版控，解決多客戶的問題
09/04 16:26, 45F
→
09/04 16:28, , 46F
2. 廠商驗收通過之後，先開案做 rebase，之後再 merge
09/04 16:28, 46F
→
09/04 16:29, , 47F
3.DB schema 要跟廠商同步，這部分不能分頭搞自己的
09/04 16:29, 47F
→
09/04 16:31, , 48F
版控不能解決把兩個ui疊到同一個位置上的問題，你只能併
09/04 16:31, 48F
→
09/04 16:31, , 49F
完測試
09/04 16:31, 49F
→
09/04 16:32, , 50F
這不是merge衝突問題，版控偵測不到
09/04 16:32, 50F
推
09/04 16:38, , 51F
db schema同步如樓上所說，你們要在開發流程上控管好，再
09/04 16:38, 51F
→
09/04 16:38, , 52F
來 牽涉layout的修改應有一個人負責協調 所有需求跟改動
09/04 16:38, 52F
→
09/04 16:38, , 53F
都必須經過他安排，就不會有兩個功能預計放在同一個位置
09/04 16:38, 53F
→
09/04 16:38, , 54F
這個窗口就是layout跟db修改的critical section
09/04 16:38, 54F
推
09/04 16:43, , 55F
怎麼會偵測不到ui衝突，只是自動化測試比較難
09/04 16:43, 55F
→
09/04 16:47, , 56F
都是加上去的是不會有衝突,版控會自動合併
09/04 16:47, 56F
→
09/04 16:47, , 57F
run起來很醜又是另外一回事了
09/04 16:47, 57F
推
09/04 16:49, , 58F
UI的部分真的困難...
09/04 16:49, 58F
推
09/04 18:16, , 59F
等等，原po你說的有點矛盾，在本來branch加上去的ui不會
09/04 18:16, 59F
→
09/04 18:16, , 60F
衝突沒錯，所以也不會醜才對吧？
09/04 18:16, 60F
推
09/04 18:18, , 61F
會醜醜ui位置跑掉的通常是auto merge後出現的不是嗎？
09/04 18:18, 61F
推
09/04 18:20, , 62F
所以auto merge完ui都要自動測試或給測試者測完才deploy
09/04 18:20, 62F
→
09/04 18:20, , 63F
不是嗎？我看起來沒什麼問題，不知道原po痛點在哪？
09/04 18:20, 63F
推
09/04 22:54, , 64F
如果原 po 痛點是出自測試的工作量，那就朝自動化走吧
09/04 22:54, 64F
→
09/04 22:55, , 65F
自動化不是說要你設計一個機制一鍵到底，而是儘可能省去
09/04 22:55, 65F
→
09/04 22:56, , 66F
重複的人工，例如 UI 美醜很難自動化，起碼可以試著測功能
09/04 22:56, 66F
→
09/04 22:57, , 67F
deploy 一直花人工很麻煩，就試著儘可能自動化 deploy
09/04 22:57, 67F
→
09/04 22:57, , 68F
然後找找前面 qrtt1 講的 DevOps 看看有沒有可以派上用場的
09/04 22:57, 68F
→
09/04 23:24, , 69F
謝謝^^
09/04 23:24, 69F
‣ 更多 O187 的文章
文章代碼(AID): #1Nowt-So (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 O187 的文章
文章代碼(AID): #1Nowt-So (Soft_Job)