各位ABAP公民們、特別是使用abapGit的各位,大家好。html
個人團隊和我將向你們分享我公司內引入abapGit後產生的某些開發問題。我所在的公司是一家創做SAP第三方軟件的公司,目前主要使用ABAP和UI5。git
本文專門針對ABAP方面。github
首先,咱們愛abapGit,相信大家中的不少也是同樣...網絡
咱們的git倉庫使用GitLab託管在本地,有着各類用戶友好的特性。ui
咱們至少天天push一次咱們的commit,生成版本(能夠說是一個額外的備份層)。編碼
經過使用GitLabs的代碼審查功能,也使代碼審查變得容易了許多。3d
咱們最近評估了使用分支的可能性,得出的結論是:咱們不能在現有的基礎設施之上使用它。版本控制
本文的剩餘部分將探究如何使用abapGit實現分支。code
本文連接:http://www.cnblogs.com/hhelibeb/p/7754487.html
英文原文:abapGit Branching Strategy Discussion
這就是咱們如今的工做方式。全部開發者在相同的SAP系統和代碼基礎(code base)上工做,全部人都push代碼到主「分支」上。
沒法立刻使用分支的根本緣由在於,全部開發者使用一樣的代碼基礎。開發者沒有隔離他們同事的代碼修改行爲。
因此,實現真正分支的第一步就是,分割每一個開發者的開發環境。這意味着,每一個開發者要有他本身的SAP系統來進行開發。
這帶給咱們第一個總體的不利條件:
咱們的第一個想法是,爲何不在開發者的機器上虛擬化運行SAP系統呢?
開發者在進行一項任務時,能夠push到他們的分支當中,直到它們建立一個merge request。
主開發系統(DEV)只從主分支拉取,主分支只包含被批准的merge request。
某些整體問題也打擊了咱們:
你還須要一個策略來應對如下問題:
而且,更新的頻率是?
升級看起來是個大問題,也許不用一個本地虛擬機、而是使用託管虛擬機會更好。
這樣的話,不管採起何種策略來更新,均可以更輕鬆地執行。
因此,進行這一切的優勢是什麼?
咱們的見解是:
值得爲此作出不少的努力嗎?
咱們的團隊並不知道答案。系統同步帶來的成本,看起來是巨大的。
在這點上咱們感到不舒服,所以轉向社區,但願聽到大家在這個話題上的的意見和經驗。
很是感謝,
André
參考文章:abapGit簡介