Jfrog Automotive DevOps Summit - CI/CD for C/C++

最近在研究汽車（ Automotive）產業，看到一個有趣也熟悉的議題，也就是牽扯到軟硬整合的 Automotive 產業該怎麼導入 DevOps ？以往我們熟悉的 DevOps 不就是寫好 code 把 code 部署上去營運就好？（好啦這是過度簡化版）。不過把這個情境移到 Automotive 產業就變成得更加複雜了，也順帶產生一堆需要被解決的問題，也正因為這樣才會看到 Jfrog 的 Automotive DevOps Summit。

雖然早在 2012 年研究 DevOps 工具時就知道 Jfrog ，但那時候只把它當作 Artifactory 看待，後沒就沒繼續追蹤下去，沒想到他已經轉型成 SaaS 公司並且在 NASDAQ 上市，後續還持續演進緊抓著 DevOps 的議題，有興趣的可以參考這篇文章介紹的很清楚：美股個股分析- 乘著DevOps浪潮的的SaaS公司- JFrog Ltd.(NASDAQ:FROG)。然後大概是 2019 年他們開始切入 Automotive 產業，在官網上可以看到這篇文章 Automotive DevOps: Rules of the Road Ahead，裡面描述為什麼這個議題突然變得如此重要？因為 Autonomous Cars are Code，現代的車子裡面充滿了各種微電腦和程式，更不用說未來的自駕車，下圖是一個系統裡面會有多少程式。

source: DevOps Automation Best Practices for Automotive Software Delivery

而這些程式都需要遵守這些 Rule，就很需要 DevOps 實踐：

• Rule 0: Don’t kill anyone!
• Rule 1: Should be up-to-date with the turn of a key.
• Rule 2: The car should get better over time.
• Rule 3: Reduce anxiety for drivers and developers.

鳳凰專案續作，獨角獸專案 - 企業轉型三部曲

從年初開始看英文版，並且寫了兩篇導讀：獨角獸專案導讀 I II，不過閱讀速度實在很慢，結果一拖就拖到了中文版出來了， 那正好就趁著年底一口氣把整本讀完。

我覺得獨角獸專案這本書就像星際大戰一樣，可以被分三部曲：

 

《星際大戰四部曲：曙光乍現》

 

其實書中的第一部和第二部都被我歸類在星戰第一部曲，就如同我之前兩篇導讀（獨角獸專案導讀 I II）所說的，著重在鋪陳技術老舊與商業挑戰的大背景，主角在充滿 Silo 和官僚的組織努力找出機會，最終被反抗軍發現且招募，並且開始跟反抗軍找出死星的弱點：就是整個「鳳凰專案」中最重要的瓶頸與核心服務所在 （數據部門），並且透過一連串的工程手段，業務隔離..等方法，試圖抽離出一個新的業務路徑 「獨角獸專案」，並且找到一個最小可執行但是影響商業甚巨的黑五推薦產品方案，取得小勝利....

第一部曲的重點五大理念：

1. 第一個理念：區域性與簡潔性
2. 第二個理念：專注，流暢和快樂
3. 第三個理念：持續改善日常工作
4. 第四個理念：心理上的安全感
5. 第五個理念：以顧客為中心
   

第一部曲給我的啟發： 

專注在影響圈

每個公司都有每個公司的問題，你永遠可以做一個抱怨公司哪裡做不好，卻依舊困在體制內的人，或是可以嘗試做出影響和改變，其實就是專注擴大在影響圈，縮小關注圈的範圍。

 圖片來源：經理人 2012.11.12 《先改變自己，才能擴大影響力、改變他人！》

 

當然自己的力量也許是很小的，所以在這段期間內也可以尋找和吸引更多志同道合的伙伴一起做出改變，加速擴大影響圈的範圍。

善用槓桿（Leverage）

再來就是人微言輕，當你沒拿出些成績時，別人當然可以不把你說的話當作一回事，在第一部曲的反抗軍們，就找出整個公司的瓶頸處，並且判斷把數據部門獨立出來運作機會比較大，就算出錯傷害也比較小，而且還可以直接影響到商業成果，可以說是花最小的 effort 取得最大的戰功，接下來改革才有希望。

微服務架構或單體式架構?先從團隊認知負擔談起

Team Topologies: Organizing Business and Technology Teams for Fast Flow

自從鳳凰計畫以後都一直有訂itrevolution.com 在 SoundCloud 上的頻道



今天一早推送的新書試聽 Team Topologies 的新書，一聽驚為天人，感覺正在回答我最近面對與思考的問題，有興趣的可以聽這個演講。

infrastructure as code 的組合技 Ansible + Terraform

圖片來源：HASHICORP TERRAFORM AND RED HAT ANSIBLE AUTOMATION

今天在 Cloud Native Taiwan User Group 看到這篇關於Ansible 與 Terraform 的組合技，就非常有感觸，DevOps 的核心精神之一就是 Infrastructure as Code，但是 Code 就會變成 legacy code 😂，越少去碰它，越少去維護就會臭得更快，尤其是 tool 更新後....

一個專業的雲端架構師需要具備協助建立團隊文化的能力

Google SRE implement DevOps

在Coursera 上 Google Cloud Professional Cloud Architect 的課程，原本以為是一個以技術為主的課程，上了之後才發現遠遠不只這些，而且有需多部分發人省思，一個專業的雲端架構師除了技術上要協助客戶釐清需求外，更重要的是幫助客戶完成商業需求，甚至要協助建立團隊的開發維運文化！

從法律經濟學的責任監管問題談 DevOps 間的關係

這題目是不是看起來有點太高深了，怎麼還可以跟DevOps扯上關係？

會有這樣的聯想，主要是啟發自薛兆丰的北大經濟學 - 法律經濟學單元，談論的主題是責任與監管問題，聽完的當下就突然覺好多東西似乎都可以用法律經濟學的角度來分析與解釋，因為在現實世界中很多東西都是 Tradeoff，不是非黑及白，但是總還是得做出判斷和抉擇，這時候法律經濟學的一個重要作用，那就是通過經濟分析，給我們的決策者提供可行性方案的比較和選擇。

鳳凰項目沙盤推演 workshop 遊戲流程

話說這本鳳凰項目 - 沙盤特別版在市面上買不到，只有授權的原廠才有賣，在開始介紹遊戲流程前，先解說一下這個遊戲的由來：

鳳凰項目 DevOps 沙盤是由歐洲著名沙盤遊戲研發機構 Gaming Works 的創始人 Jan Schilt 先生聯手《鳳凰項目》一書的作者 Gene Kim 先生，開發的同名沙盤演練課程。  鳳凰項目沙盤演練覆蓋了業務場景中所有的職員角色，尤其是那些從事 IT 開發以及 IT 運維工作並希望通過精益(LEAN), 敏捷（AGILE）和 IT 服務管理流程如（ITIL®）等最佳實踐來提高 IT 服務表現或通過 IT 解決方案為業務創造價值的 IT 專業人士。該沙盤同時也是為那些通過創建更好的協作氛圍並最終實現更高效以及更精確的 IT 解決方案部署的企業。

延續上一篇 -  鳳凰項目沙盤推演 workshop 感想，在這邊我先大略描述一下遊戲的內容與大致的流程，遊戲設計的角色，以及要做的工作。

鳳凰項目沙盤推演 workshop 感想

原本想要下的標題是 "紫衣教" 老司機們團報踢館鳳凰項目沙盤推演 workshop ~XD

話說這次參加鳳凰項目沙盤推演 workshop 的成員組成，除了少數不知道怎麼被拐來的人(還是有人連鳳凰項目書都沒看過就被拐來)，大部分的都是敏捷界的老司機，粗略估算一下組成和經歷：

• 80% 被Daniel 開過腦洞
• 40% 有參加過ICA 辦的引導型敏捷領導力課程
• 30% 有參加過呂毅 Less

有參加過這幾種課程培訓的，參加這種workshop 根本就是小菜一盤，首先的起手式就是把工作視覺化，一開始就透過 Kanban 來安排工作，甚至還不斷的演進，每一輪都更新我們看板的格式，為了就是讓工作更加順暢。

書摘 - 鳳凰計畫 (The phoenix Project )

圖片來源：itrevolution.com

任何理論和方法論都是為了解決某些情境下產生的問題，但對於大多數執行者或是遵行者來說這些方法論都只是優化後的結果，並沒有像Design pattern 一樣說明這些方法是為了解決什麼問題，如果不用會產生什麼問題....不過透過小說描述慘況讓讀者感同身受(這些都是我們會遇到的)，再搭配解決的方法 (或是解決方法的演進)，的確會是比較容易吸收，於是乎就有了這本書：

The Phoenix Project - A Novel About IT, DevOps, and Helping Your Business Win.

Jenkins Docker Plugin - 讓你的Build 不用排隊太久的方法一

圖片來源：loof

關於什麼是Jenkins以及使用Jenkins的好處可以參考之前的文章 - 邁向自動建置佈署之路(2) -安裝 Jenkins ，在這邊就不多介紹。在本篇文章我們要介紹為什麼要使用Docker Plug-in? 為了解決什麼問題？

[筆記] 如何把你的open source 專案 納入maven central repo

要如何把你的open source 專案 納入maven central repo呢？常在很多open source 專案的parent pom.xml看到這樣的設定：

 <parent>
    <groupid>org.sonatype.oss</groupid>
    <artifactid>oss-parent</artifactid>
    <version>7</version>
  </parent>

原來這就是把專案加入maven repository 的方式，現在maven central repository 是由sonatype這個組織在管理，關於sonatype的介紹如下：

sonatype OSSRH (OSS Repository Hosting Service) uses Nexus to provide Maven repository hosting service for open source projects: https://oss.sonatype.org/. You can deploy snapshots, stage releases, and promote your releases so they will be synced to The Central Repository. All you need to do is to sign up a Sonatype JIRA account, create a JIRA ticket and make some POM/settings configuration. This document will guide you step by step for the details.

參考這份文件Sonatype OSS Maven Repository Usage Guide，步驟如下：

1. 決定你Release 的 License

2. 申請一個Sonatype JIRA account

3. Create a JIRA ticket

4. 設定要deploy 到哪個repository

ApacheCon2013 - Continuous Delivery with Maven, Puppet and Tomcat

Source：Carlos Sanchez - Continuous Delivery with Maven, Puppet and Tomcat

參加ApacheCon2013的筆記持續整理消化中....Orz..

話說在DevOps 的概念裡面本來就有包含QA的概念，不過很多時候卻被人誤解成，不需要QA或者是QA不重要，因此講者就在投影片引用一句話：

To make error is human. To propagate error to all server in automatic way is  Devops

所以越是自動化的部屬，就越需要QA的參與，所以講者就特別把QA獨立出來強調，因此才有DevQaOps的詞..XD 其實目的都是為了能達到Agile - Continuous Delivery 的境界。

雖然之前我有整理過一篇文章關於DevOps的工具與技術 -  Continuous delivery - tools and techniques ，但是對於這塊的著墨還是略嫌不足，而這次參加這個Session

這篇文章列出一堆幫助DevOps的工具與技術，而這個Session 雖然題目是寫Maven + Puppet + Tomcat 的組合，但是裡面主要介紹必較新奇的技術卻是 "Puppet + vagrant" 的組合，透過Puppet + vagrant 的組合能快速的建立vm環境和開發環境，加速複製和重建的時間，然後也可以利用puppet 控制maven 的安裝與控制，詳細的範例可以參考講者放在Github上的範例專案：

• Continuous Delivery with Maven, Puppet and Tomcat
• https://github.com/carlossg/continuous-delivery
• puppet + vagrant + maven 的組合
• https://github.com/maestrodev/puppet-maven

延伸閱讀：

• From Dev to DevOps with Maven and Puppet
• Provisioning Maven artifacts with Puppet

投影片：

Continuous Delivery with Maven, Puppet and Tomcat - ApacheCon NA 2013 from Carlos Sanchez

後記：

因為筆者都在介紹Puppet我就好奇，那Chef呢？因為這也是常見常聽到的技術，所以我就順便Google了 Chef 與 Puppet之間的差異。

• Chef vs Puppet – my take on the holy war
• Puppet or Chef?
• What is the difference between Chef and Puppet in configuration management software?
• Puppet versus Chef: 10 reasons why Puppet wins

簡單來說就是Chef 是新公司做出來的產品，有著跟Puppet相同的目標但是不同的技術，所以Puppet陣營的說法就是Chef沒有經過大型系統Deploy 的驗證與知名公司的背書 (不過最近Facebook採用了~:P)

所以同樣的也有Chef 跟Maven 整合的專案和套件：

• https://github.com/opscode-cookbooks/maven
• https://github.com/bryanwb/chef-maven-bin#readme