iT邦幫忙

2017 iT 邦幫忙鐵人賽
DAY 13
0
DevOps

CI 從入門到入坑系列 第 13

開發如何考慮維運

CI 講了這麼久,大家也許會覺得跟維運人員好像沒什麼太大關係,因為幾乎都環繞在測試上。今天來聊聊 DevOps 的其中一半:開發如何考慮維運

測試是測上線的過程

先破題,不管是哪種測試,都是在假設上線的狀況下執行不是嗎?所以測試本身就是站在維運的角度看程式了。範圍比較小的單元測試也許比較無感,但擴大到跟其他元件的整合測試時,其實就會發現某些測試會需要維運人員協助,如手動測試前,必須先把所有依賴服務與測試機器都先準備好,接著把程式佈署上去才能開始測。

所以開發要如何考慮維運呢?其實「概念上」非常地簡單,只要要求開發人員每次測試都親自做就行了!

這是要逼死誰?

或許會有開發人員抗議,明明佈署測試機器是維運的事,為何要開發自己來?還記得 Day 2 提到的 Hello World 嗎?開發人員測程式,本來就該知道測試的環境要如何佈署了,這沒有抗議的道理。但環境佈署通常有固定的模式,而這正是維運人員拿手好戲,所以可以由維運人員撰寫腳本,讓開發容易地在任何地方建立起基礎環境。

而開發人員每次測試都需要佈署程式,佈署方法很多,但概念上都是把可執行的程式丟到基礎環境上,另外同時也把環境的設定初始化,最後就是資料遷移,都完成後才開始測。以測試 3A 的角度來看,這是 Arrange 的過程。這個過程應該是開發人員最熟悉的,畢竟是寫程式的人,應該會非常清楚如何佈署。

所以前面基礎環境可以由維運人員寫腳本變成一行指令建機器,後面開發人員只要讓佈署變得簡單快速,那對維運人員就太完美了。

如何簡化佈署流程?

上面有提到佈署的過程,其實不外乎三個重點。

  • 更新程式
  • 更新設定檔
  • 資料遷移

更新程式,通常 compile 跟可執行檔都有固定對應的上傳路徑,這部分是可以自動執行的。資料遷移也有固定的方法,也可以執行。佈署常出現一個好像需要人為介入的部分,叫設定。好像也沒錯,帳密設定是由人手動加入的,但沒人會想在原始碼裡放帳密。因此有一個常見的解法,稱為環境變數。環境變數正如其名,它是變數,不過是因環境而變。幾乎所有系統都有環境變數的實作,也幾乎所有語言都可以取得目前環境的變數值。

因環境變數是定義在系統上,不同的環境,就應當要有不同的環境變數。定義在系統裡的好處是,程式的更新會跟環境無關。這樣的做法,在佈署的時候就不會把設定值取代掉,而繼續沿用之前的設定。程式在取得不同的環境變數後就可以做不一樣的行為,如開發者可以開啟 debug 模式,而正式上線不開啟。

聽起來好像很厲害,那該如何寫呢?比方說上例的 debug 模式可以這樣寫:

<?php

$debug = getenv('DEBUG');

於是 $debug 的變數就會取得環境變數 DEBUG 的值,再去做後續的處理。

開發做這有什麼好處嗎?

嚴格說起來,是不一定!但如果需要管理多個環境時,絕對會認為這是神器。比方說像我開發需要管理的環境有三種

  • Notebook
  • Docker
  • CI Server

開發通常會有支援檔案整合環境變數的套件,通常查 dotenv 都會有相關的資訊,這部分就跳過。 Docker 如果用 Docker Compose 可以這樣定義:

server:
  image: php:7.0-apache
  environment:
    DEBUG: 1

上例就是打開 debug 模式。 CI 也有類似的做法,如 CircleCI 是這樣定義的:

machine:
  php:
    version: 7.0.7
  environment:
    DEBUG: 0

CI 我不想開 debug 模式,那這樣設定即可。

是的,不需要寫腳本去做字串 replace ,也不需要擔心機敏資料被別人發現,它只要在存在機器裡就能繼續被使用。理想上,佈署只要整包程式丟上去,設定不需要調整就能直接 work 了。

今日回顧

雖然是說「要求開發人員」,但實際上是大家共同寫出一個自動化系統,讓開發人員方便測試並快速取得結果。最終目的還是為了 CI 精神!

相關連結


上一篇
測試範圍
下一篇
到處流浪的伺服器
系列文
CI 從入門到入坑30

1 則留言

0
凍仁翔
iT邦新手 4 級 ‧ 2016-12-14 01:13:43

好個開發模式,受教了!

話說不少開發人員都不會寫 README 或文件給維運人員,往往到了要上線時才發現不能動 …。/images/emoticon/emoticon03.gif

Miles iT邦新手 4 級‧ 2016-12-14 10:05:30 檢舉

考慮維運人員其實只是一部分,我覺得其實真正受惠的是開發人員本身。才發生線上問題時,通靈的機會就比較少(有文件可以參考嘛);或是當有其他成員加入團隊時,就會非常開心(有文件可以參考嘛XD)

一但 bug 變少了,就會有更多的時間可以開發新的 feature!

我要留言

立即登入留言