1. 程式人生 > >abapGit分支策略

abapGit分支策略

是個 rdquo code git分支 至少 情況 alt 你會 域名

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

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

本文專門針對ABAP方面。

首先,我們愛abapGit,相信你們中的很多也是一樣...

技術分享

GitHub repository

我們的git倉庫使用GitLab托管在本地,有著各種用戶友好的特性。

我們至少每天push一次我們的commit,生成版本(可以說是一個額外的備份層)。

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

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

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

本文鏈接: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分支策略