abapGit分支策略

各位ABAP公民們、特別是使用abapGit的各位,大家好。html

個人團隊和我將向你們分享我公司內引入abapGit後產生的某些開發問題。我所在的公司是一家創做SAP第三方軟件的公司,目前主要使用ABAP和UI5。git

本文專門針對ABAP方面。github

 

首先,咱們愛abapGit,相信大家中的不少也是同樣...網絡

GitHub repositoryide

咱們的git倉庫使用GitLab託管在本地,有着各類用戶友好的特性。ui

咱們至少天天push一次咱們的commit,生成版本(能夠說是一個額外的備份層)。編碼

經過使用GitLabs的代碼審查功能,也使代碼審查變得容易了許多。3d

咱們最近評估了使用分支的可能性,得出的結論是:咱們不能在現有的基礎設施之上使用它。版本控制

本文的剩餘部分將探究如何使用abapGit實現分支。code

 

本文連接:http://www.cnblogs.com/hhelibeb/p/7754487.html

英文原文:abapGit Branching Strategy Discussion

場景1:無分支

這就是咱們如今的工做方式。全部開發者在相同的SAP系統和代碼基礎(code base)上工做,全部人都push代碼到主「分支」上。

優點

  • 更好的代碼版本控制
  • 易於進行代碼審查

劣勢

  • 分支是不可能的,開發者同時在一樣的代碼基礎上修改對象
    • 切換分支時,會改變每一個開發者的代碼基礎,雖然他們也許會覺得本身還在他們的分支上
  • 代碼會由於其餘人的問題commit出錯
    • 甲修改了對象A,乙後來也修改了它
      甲在不知道乙修改過A的狀況下進行了commit
    • 是的,進行最後一個修改的人能夠在abapGit工做臺上面看到這個,可是,你仍然有可能沒看到它。

場景2:使用分支

沒法立刻使用分支的根本緣由在於,全部開發者使用一樣的代碼基礎。開發者沒有隔離他們同事的代碼修改行爲。

因此,實現真正分支的第一步就是,分割每一個開發者的開發環境。這意味着,每一個開發者要有他本身的SAP系統來進行開發。

這帶給咱們第一個總體的不利條件:

  • 開發者數量的增長帶來的高昂的維護費用。

Local VMs

咱們的第一個想法是,爲何不在開發者的機器上虛擬化運行SAP系統呢?

開發者在進行一項任務時,能夠push到他們的分支當中,直到它們建立一個merge request。

主開發系統(DEV)只從主分支拉取,主分支只包含被批准的merge request。

優點

  • 鏈接到你的SAP系統時,不須要網絡接口
  • 你能夠在不鏈接公司網絡的狀況下開發
    • 只須要在push代碼到git倉庫的時候才須要鏈接公司網絡
  • 在SSD上面運行SAP系統真的快極了

劣勢

  • 高維護開銷
    • 管理員對機器的控制比較難
  • 開發者須要知道怎樣開啓/關閉他們的虛擬機/SAP系統
    • 甚至可能須要他們本身定時備份虛擬機    

 

某些整體問題也打擊了咱們:

升級開發者的SAP系統

  • 如何給系統打補丁(支持包,notes,系統級補丁)?
  • 當須要獲取定製數據、主數據和業務數據來開發新特性、重現bug而且修復時,要怎樣獲取它們?

升級主開發SAP系統

  • 如何處理abapGit不能序列化的開發對象?
  • 當須要獲取定製數據、主數據和業務數據來開發新特性、重現bug而且修復時,主開發系統要怎樣獲取它們?
  • 從主分支拉取代碼後,要如何處理開發對象以把它們分配到合適的傳輸請求之上?
    • 也許你有個複雜的傳輸規則以幫助代碼複用。咱們就是如此。

你還須要一個策略來應對如下問題:

  • 爲沒法序列化的對象單獨維護和配置以及單獨地導入定製和工做臺傳輸
    • 聽起來像一團糟
  • 開發系統的複製(只複製SAP)
    • 只是爲了給你定製數據
  • 克隆主開發系統運行的虛擬機(OS+SAP)
    • 而且重命名SID和全稱域名(Full Qualified Domain Name),不然你會遇到網絡問題
  • …… 

而且,更新的頻率是?

  • 按需
  • 在建立一個新分支前
  • 在一個新的發佈循環開始的時候
  • ……

Hosted VMs

升級看起來是個大問題,也許不用一個本地虛擬機、而是使用託管虛擬機會更好。

這樣的話,不管採起何種策略來更新,均可以更輕鬆地執行。

優點:

  • 管理員能夠在任什麼時候間訪問機器

劣勢:

  • 運行開發虛擬機帶來的託管成本

結論

因此,進行這一切的優勢是什麼?

咱們的見解是:

  • 真正的分支成爲可能,編碼時不干涉其它開發者
  • 因爲merge request和多個commit的結合,更加有利於代碼審查
  • 對多個發行版本的良好支持,容易切換到一個發行分支上去
  • ……

值得爲此作出不少的努力嗎?

咱們的團隊並不知道答案。系統同步帶來的成本,看起來是巨大的。

在這點上咱們感到不舒服,所以轉向社區,但願聽到大家在這個話題上的的意見和經驗。

 

很是感謝,

André

 

參考文章:abapGit簡介

相關文章
相關標籤/搜索