當(dāng)前位置：首頁 > 嵌入式培訓(xùn) > 嵌入式學(xué)習(xí) > 行業(yè)百科 > 在版本控制中嵌入式軟件工程師需要了解什么
在版本控制中嵌入式軟件工程師需要了解什么
時(shí)間：2020-05-06 來源：原創(chuàng)
在過去的幾年中，版本控制（實(shí)際上已成為嵌入式軟件開發(fā)過程的一部分）已發(fā)生了很大變化。這對任何組織審查其版本控制策略并在版本控制工具上進(jìn)行投資都具有重大意義。
最大的發(fā)展之一是Git的流行，Git是最初在Linux世界中開發(fā)的開源版本控制系統(tǒng)，但現(xiàn)在已被廣泛使用。Pure Git專為獨(dú)立工作和分布式本地化版本而設(shè)計(jì)，沒有中央服務(wù)器功能。Git的吸引力之所以可以理解是因?yàn)樗鼮閭�(gè)人開發(fā)人員提供了一些引人注目的好處–價(jià)格便宜，設(shè)置迅速，并為個(gè)人或中小型團(tuán)隊(duì)提供了所需的快速，靈活的版本控制和工作流程。
盡管許多傳統(tǒng)的嵌入式軟件開發(fā)人員可能并不歡迎Git，但大學(xué)畢業(yè)的新一代工程師是–以及諸如Agile之類的新開發(fā)方法。
Git確實(shí)有一些限制，但是可以在一定程度上克服這些限制。稍后再詳細(xì)介紹，但首先，GitHub應(yīng)該得到解釋，因?yàn)樗?jīng)常在與Git相同的對話中被引用。Git是一個(gè)版本控制工具，而GitHub是Git管理工具，它為用戶提供了一個(gè)通用的位置來存儲(chǔ)所有已創(chuàng)建的Git存儲(chǔ)庫，從理論上講，它使管理起來更加容易。GitHub負(fù)責(zé)推廣Git，但它當(dāng)然不是唯一的Git管理工具，其他工具各有不同的功能和方法。
并行開發(fā)
在Git興起的同時(shí)，軟件開發(fā)的本質(zhì)也發(fā)生了變化。項(xiàng)目變得越來越大，越來越復(fù)雜，通常涉及分散在世界各地的更大的團(tuán)隊(duì)。用戶不僅希望對源代碼進(jìn)行版本控制，還常常希望包含二進(jìn)制文件，以將與項(xiàng)目關(guān)聯(lián)的所有內(nèi)容都放在一個(gè)位置。物聯(lián)網(wǎng)進(jìn)一步加速了這一過程。如今，即使在小型組織中，千兆位存儲(chǔ)庫也已司空見慣，這給公司施加了壓力，要求它們確保數(shù)字IP安全，可訪問和可審計(jì)，同時(shí)又不減慢開發(fā)過程。此外，我們還更加關(guān)注數(shù)字資產(chǎn)的整個(gè)生命周期，而不僅僅是其最初的開發(fā)。這些驅(qū)動(dòng)因素意味著Git的角色需要仔細(xì)考慮。
安全性
物聯(lián)網(wǎng)有使我們退縮到30年前的時(shí)間，因?yàn)槲覀冊跇?gòu)建網(wǎng)絡(luò)堆棧時(shí)沒有采取固有的安全措施，因此有遭受大規(guī)模DDOS攻擊的風(fēng)險(xiǎn)。圍繞安全性，各種軟件開發(fā)都需要更加嚴(yán)格和盡職調(diào)查；不僅要滿足合規(guī)性和法規(guī)要求，還要滿足安全性要求。Git的體系結(jié)構(gòu)不包括經(jīng)過驗(yàn)證的歷史記錄之外的安全性（無身份驗(yàn)證，無權(quán)限）；但這并不是批評，因?yàn)樗⒎侵荚谧鳛榘踩ぞ摺?br />
Git管理可用于引入安全性，但是安全性的性質(zhì)和級別會(huì)有所不同。有些工具提供了在存儲(chǔ)庫級別上對文件的訪問，因此安全性是一無所有：用戶可以訪問存儲(chǔ)庫中的所有文件，或者根本不能訪問。其他工具在存儲(chǔ)庫和分支級別提供訪問控制。更高級的工具可提供更細(xì)粒度的安全性。例如，Perforce Helix提供了跨IP地址，用戶和組的訪問控制（以及試圖訪問的任何人的可見性），并且在本地或授權(quán)位置的代碼存儲(chǔ)庫，分支，目錄或單個(gè)文件級別具有可執(zhí)行性。
大規(guī)模開發(fā)
Git對于許多較小的項(xiàng)目和團(tuán)隊(duì)來說是不錯(cuò)的選擇，但是當(dāng)項(xiàng)目增長時(shí)，它很快就變得毫無用處。這是由于它的體系結(jié)構(gòu)：一個(gè)Git存儲(chǔ)庫在內(nèi)部組織成一棵樹，其中每個(gè)節(jié)點(diǎn)代表對一組文件的更改，并通過散列對其之前的更改進(jìn)行加密保護(hù)。每個(gè)存儲(chǔ)庫都需要提供其整個(gè)歷史記錄，因此，在大型項(xiàng)目中，下載（“克隆”）存儲(chǔ)庫可能會(huì)從幾秒鐘縮短到幾分鐘甚至幾小時(shí)。
縮小項(xiàng)目規(guī)模不是一個(gè)選擇：用戶會(huì)被最初指定的Git存儲(chǔ)庫配置所困擾；它無法拆分。擁有大量存儲(chǔ)庫是一些組織嘗試的一種方法，但是正如他們發(fā)現(xiàn)的那樣，管理數(shù)百個(gè)Git存儲(chǔ)庫非常困難-因此，術(shù)語“ Git蔓延”。不再有整個(gè)項(xiàng)目的單一視圖。雖然可以將所有這些存儲(chǔ)庫重新“縫合”在一起，但這會(huì)帶來很多額外的工作。在廣泛采用Git的組織中，雇用團(tuán)隊(duì)來管理Git并不少見，因此使Git變得可行所需的進(jìn)一步投資可能會(huì)抵消Git最初的低成本。
Git管理工具會(huì)有所幫助，因?yàn)樗鼈兛梢栽诤艽蟪潭壬咸砑臃椒�，以使Git在大型環(huán)境中更易于管理。例如，Perforce Helix使用戶可以靈活地將項(xiàng)目回顧性地分成較小的塊。事實(shí)證明，Git管理工具非常流行，并且確實(shí)可以解決一些實(shí)際問題。同樣，盡管很難向開發(fā)人員強(qiáng)制要求他們不能使用Git，但許多知道無法避免復(fù)雜的大規(guī)模開發(fā)環(huán)境的組織選擇盡可能避免使用Git。
“ Git對于許多較小的項(xiàng)目和團(tuán)隊(duì)來說很好，但是當(dāng)項(xiàng)目增長時(shí)，它很快變得毫無用處。” 斯文·埃里克·諾普（Sven Erik Knop）
“單一事實(shí)來源”
在嵌入式開發(fā)中，組織通常希望將與項(xiàng)目相關(guān)的所有內(nèi)容都包含為“單一事實(shí)來源”，所有數(shù)字資產(chǎn)都集中在一個(gè)地方，完全可追溯且可見。它日益被視為DevOps的基本要求，并通過提供項(xiàng)目的單一，不變的歷史記錄來支持合規(guī)性流程。
在嵌入式市場中，開發(fā)環(huán)境通常包括各種各樣的二進(jìn)制文件，這些文件通常很大且格式不同。問題在于二進(jìn)制文件在Git中不容易版本化-即使使用GitLFS也會(huì)導(dǎo)致大量資產(chǎn)更新-因此公司最終可能會(huì)在其他系統(tǒng)中存儲(chǔ)二進(jìn)制資產(chǎn)，從而破壞了“單一事實(shí)來源”。此外，項(xiàng)目可能包括軟件開發(fā)團(tuán)隊(duì)之外的人員，他們認(rèn)為Git不易于使用。
混合解決方案
雖然Git不會(huì)很快消失，但是與復(fù)雜的大型開發(fā)項(xiàng)目相關(guān)的問題也不會(huì)消失。有多種選擇，包括同時(shí)支持Git和其他版本控制環(huán)境（例如Perforce Helix），分布式和集中式版本控制的混合系統(tǒng)。諸如“狹窄克隆”之類的技術(shù)還可以通過將無用的源代碼分成較小的塊來提供幫助，但是，這又是組織必須在工作量和預(yù)算中考慮的額外工作。
總體信息是：Git提供了很多功能，并且在將版本控制帶給新用戶方面發(fā)揮了巨大作用。但是，當(dāng)項(xiàng)目開始擴(kuò)展或變得更加復(fù)雜時(shí)，尤其是在成本，安全性，速度和靈活性方面，其企業(yè)級部署需要仔細(xì)考慮和管理。幸運(yùn)的是，實(shí)現(xiàn)這一目標(biāo)的方法越來越多，而且這些方法還將繼續(xù)發(fā)展，從而為公司提供更多選擇。
