[淺談]從製造業角度看 CI / CD 這件事

Edward Kuo
Jun 12 · 7 min read
Image for post
Image for post

本篇是從製造業IT部門角度看所謂的 Continuous Integration 和 Continuous Delivery ,企業的IT部門主要任務是要能維持企業營運的系統,以及面對許多非常客製化的需求與開發

Continuous Integration 和 Continuous Delivery 在市面有許多關於這方面的書籍,也有很多關於這方面做法與分享,不過,對於製造業的IT部門來說,Continuous Integration 和 Continuous Delivery 有時候並不只是技術上的問題,有很多時候反而是現實上的問題。所謂現實問題大概會有以下幾點:

  • ERP & MES 這種系統,怎樣做?
  • 那種老舊到不行的系統,怎樣做?
  • 生產線內的系統,怎樣做?
  • ………..

除了,上述幾點外,我想相信不同企業的Policy不同,還是會衍生出其他現實的難處出來。還有,姑且說一些無法進行CI / CD的系統外,若是,把可以做CI / CD的系統列出來,大概也可以產生上百個CI / CD Pipeline(這還可能只是一個開發部門的量),因此,可想而知,要如何管理這樣多Pipeline又將會是一門學問。

Image for post
Image for post

選擇性的做CI / CD

如我前面提到大部份製造業的MES和ERP,這兩大核心系統,很多時候都是購買、外包開發且甚至是套裝軟體,經過一段時間才會有企業內部人員進行維護或是開發,這類系統其實要做到CI / CD 並不容易,此外,這兩類型的系統可以說是製造業的命脈,在短時間內可能要讓所有人可以放心的CI / CD,只能說這中間要過的坎是非常多的,包含技術、人員以及稽核流程。這類型的系統,我個人認為並非真的需要導入CI / CD,就整個風險看來還是相對是高。有些公司如果MES的自製比率是高的,如果把MES透過模組方式解耦,將有機會進行CI / CD,但這前提就必須經過一段時間的陣痛期

再者,在製造業往往那種十年前開發過的系統,到現在還在持續使用與修改,這種現象是比比皆是,甚至,大多數年輕工程師搞不好還沒有學過這系統的開發語言呢,這時候要來做CI / CD,一方面也不一定有這樣機制可以進行,另一方面,可能要花費相當大的代價才可能成功。這時候,說不定進行系統改寫或是翻新,再來進行CI/CD的價值會更高

至於生產線上系統呢? 如果本身是可以進行CI,那樣就必須把CD這部分區分出Release & Deploy兩個階段,我們可以不斷進行持續整合與發佈,但是,最終佈署到正式生產環境則需等到"良辰吉時"才可以,或許這樣是否就達不到DevOps所謂的一天發布上百次的境界呢?這樣會是DevOps嗎?我個人覺得如果可以一天進行多次的CI / CD (到Release 這步驟),就可以算是達到DevOps的環節,至於,有沒有機會達到一天多次佈署呢? 我只能說就現在整個製造業環境來說是非常困難的。

也因此,再進行CI / CD的導入,其實也必須選擇性去導入,也並非一定要到達全方位的CI/CD才算是有進行DevOps

讓CI / CD 是一種標準化的產出流程

Image for post
Image for post

雖然,有些系統不適合作CI/CD,但還是有大多數系統是可以實作CI/CD,而在製造業中,系統是非常多,但也非常的零散,除了ERP或是MES。此外,Continuous Integration 和 Continuous Delivery本身帶來效益之外,另外一個好處,就是可以作為一個標準交付系統的通道。因此,在每次交付整合都是透過CI/CD來處理,就可以在此通道設定許多檢核關卡,像是測試就是其中一種,也可以設置一些需要在開發人員注意的一些Check Point,如果沒有符合這些Check Point就不被允許交付。

不過,我覺得想要邁入CI/CD第一步,就是可以先要取代人工佈署這件事情,因為,在製造業有些系統其實不並大,簡單來說可能就只是一個應用程式而已,但是,想說只是一個應用程式,直接用人工佈署就可以。這樣做法往往會忽略一些Check Point,甚至有可能忘記去修改應用程式參數來符合正式環境的需要。這個系統或是應用程式都已經可以透過人工方式佈署,然而要做自動化的佈署想必就不會那樣困難。不過,有時候,可能有人認為說這只是一隻小程式,透過人工佈署都比去建立一個CI/CD來的快。不過,這或許是當下正在進行開發的時候,對這個程式的佈署與建志芳是很熟悉是可以這樣說。但是,當程式是由別人維護或是過陣子再來維護與修改,是否還可以這樣熟悉呢?

逐步導入方式會比一次想要全面導入模式簡單許多,也可以因應自己企業的文化特性建立出想對應的Pipeline。

此外,除了本身CI/CD建置有其技術外,另外最大困難點可能就是由誰來建置這樣的Pipeline,而建置這些Pipeline可能還會遇到跨部門的刁難或是一些阻礙,這反而是這一段最困難地方。

就CI/CD Pipeline建置而言,我認為因該是由開發團隊來建置這樣的Pipeline是比較合宜的。畢竟從開發所需要的技術與測試方式,還是開發系統會比較熟悉,到最後的發布和環境變數需要那些設定,也是開發者會比較熟悉,在做這些事情上面會比較順手,至於,需不需要多一組團隊專職做這件事情,至少我認為在這個產業很難說服老闆多建立一個團隊來搞定這些。

此外,CI/CD設計上是一種標準化的通道,即使在多樣性的開發以及複雜的佈署環境,也可以確保每個人在系統或是應用程式開發上盡可能地保持一致性,降低後期維護或維運的困難性,還有就是人是很容易健忘的,尤其在這產業每天快速的Content Switch是家常便飯的事情。

CI / CD 重要性

此外,我個人覺得另一個重要性可以降低這系統在我電腦是可以Build成功或是可以跑的這件事情。畢竟,CI/CD不可能在自己電腦執行(如果有人把這件事情是放在自己電腦,那....),此外,也可以降低或是避免人員都必須登入到正式環境或是Server去佈署系統所帶來的風險。

最後,相信在網路也可以找到很多一定要做CI/CD的優點,但要如何說服上面主管肯投入資源或時間導入CI/CD,在一般企業是會有一定難度存在,有些時候CI/CD的成效也不會是立即就可以見效。所以,也建議一開始必須要把CI/CD搞得太複雜,也有助於推進CI/CD。

至於,我們是怎樣設計與管理Pipeline,有空再繼續寫下去…

EK.Technology Learn

Design,Thinking,Coding & have fun every thing

Edward Kuo

Written by

Enterprise IT Manager / Microsoft Regional Director / Microsoft MVP / DevOps Expert / Speaker, About me: https://profile.edwardkuo.dev/about/

EK.Technology Learn

Design,Thinking,Coding & have fun every thing

Edward Kuo

Written by

Enterprise IT Manager / Microsoft Regional Director / Microsoft MVP / DevOps Expert / Speaker, About me: https://profile.edwardkuo.dev/about/

EK.Technology Learn

Design,Thinking,Coding & have fun every thing

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store