搜尋

搜尋結果

Ubuntu 24.04 試用報告-更新
科技新知
MacauYeah・2024-05-21

上期為大家介紹了一些ubuntu docker, multipass的一些改動。本期再繼續介紹一些其他的更新。 apt中的source.list 的位置更新了,格式也更新了,從etcaptsources.list在指向了etcaptsources.list.dubuntu.sources,格式變得更親民,就像如下所示 Types deb URIs httpmo.archive.ubuntu.comubuntu Suites noble nobleupdates noblebackports Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg Types deb URIs httpsecurity.ubuntu.comubuntu Suites noblesecurity Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg 承上更新,雖然格式好看了,noblesecurity的部份卻故意折開了。而且在livecd初次安裝時,大家若要改mirror鏡像站點,只能修改noble nobleupdates noblebackports的位置,noblesecurity還是會指定在官方的位置。筆者猜測它的用意是針對安全性更新,大家應該要直接訪問官方網站,不要等mirror慢慢更新。此一更新,不單影響ubuntu 24.04,連ubuntu 22.04也受一併折開了,只是22.04還是使用舊版。如果有需要變回統一的方向,減少日後自動化的修改,可以像以下修改 ubuntu 24.04的修改 Types deb URIs httpmo.archive.ubuntu.comubuntu Suites noble nobleupdates noblebackports noblesecurity Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg ubuntu 22.04.04的修改,刪除etcaptsources.list,新增etcaptsources.list.dubuntu.sources 對齊ubuntu24的位置 Types deb URIs httpmo.archive.ubuntu.comubuntu Suites jammy jammyupdates jammy backports jammysecurity Components main restricted universe multiverse SignedBy usrsharekeyringsubuntuarchivekeyring.gpg

Git - 持續整合策略 | Git - Continuous integration strategy
科技新知
MacauYeah・2024-02-23

對於原始碼的管理,平常筆者也有在用gitlab的Continuous integration,針對每次提交commit,都會有自動編譯和測試。但當一個專案中,有很多關聯庫dependency library的引用時,光是專案中每個commit 行auto build就不夠用了。更嚴重的是,若然大家有很多微服務micro service,它們的更新不會反映在commit中。 所以定期重跑動動編譯和測試,是筆者認為可以緩解關聯更新的問題,至少可以提高知道問題所在。 筆者先做了一些功課,參考別人怎樣思考Night build (定期重新編譯)這件事。 每次整合新功能到穩定分支(stable branch)之前,都需要做自動測試。 當專案複雜性越來越大,每次自動測試都把全部測試跑一次,就會遇到效能瓶頸。 所以考慮commit時做單元測試(unit test),然後每個固定的時間問隔做整合測試(integration test)。那個固定的時間間隔就是Night build。 而筆者的問題並不是來自於效能瓶頸,而是涉及關聯性更新問題。這些要麼就有是經code base 層面引發關聯性自動試測,要麼就是Night build重複測試。這兩個功能,gitlab都有提供,只是筆者初步構想下,Night build比較易設定。因為要考慮micro service的於沙盒環境的部署,最簡易的Night build只需要一個共用的環境就夠。但也同樣意味著,Night build需要進行多個不同的分支測試。就需要多個不同的環境。 Night build的測時時機也是一個問題,因為測試當下,並不能百份百對應關聯micro services的提交狀況,大家就更需要做好發佈的版本號語意管理。 不知道看完筆者的策略之後,大家又有何看法?歡迎大家一起加入git筆記的編輯。