Versioning & Deploy

Workflow ของคุณรันค้างอยู่ 3,000 รายการ แต่ละรายการรอ OTP อยู่ แล้วคุณต้อง deploy โค้ดใหม่ที่เพิ่มขั้นตอนตรวจ AML ก่อนโอนเงิน พอ worker ตัวใหม่ขึ้น มันจะ replay ธุรกรรมเก่าผ่านโค้ดใหม่ — แล้วพังทั้ง 3,000 รายการ

บทนี้คือวิธีแก้โค้ดโดยไม่ทำให้ของที่ค้างอยู่พัง

ทำไมการ deploy ถึงอันตราย#

ทบทวนจากบทที่ 4: workflow ไม่ได้เก็บ state ไว้ตรงๆ แต่สร้างใหม่ทุกครั้งด้วยการ replay event history โค้ดจึงต้องออก command ชุดเดิมเป๊ะทุกครั้ง

System map

Workflow ที่เจอ non-determinism จะไม่ตายทันที แต่จะ ค้างอยู่ในสถานะ Running โดยที่ workflow task fail ซ้ำไปเรื่อยๆ ซึ่งกู้ได้ (deploy โค้ดเดิมกลับไปก่อน) แต่ระหว่างนั้นธุรกรรมของลูกค้าไม่เดิน

อะไร breaking อะไรไม่#

นี่คือเหตุผลหนึ่งที่ควรผลักตรรกะที่เปลี่ยนบ่อย (เช่นกฎ fee, กฎ limit) ลงไปใน activity แทนที่จะเขียนไว้ใน workflow

วิธีที่ 1: Patching ด้วย GetVersion#

workflow.GetVersion บันทึก marker ลง history ตอนรันครั้งแรก พอ replay มันจะคืนค่าเดิมที่บันทึกไว้ ทำให้โค้ดเก่ากับใหม่อยู่ในไฟล์เดียวกันได้

v := workflow.GetVersion(ctx, "changeID", minSupported, maxSupported)

• changeID — ชื่อเฉพาะของการแก้ครั้งนี้ ต้องไม่ซ้ำกับครั้งอื่น
• minSupported — เวอร์ชันเก่าสุดที่ยังรองรับ (workflow.DefaultVersion = -1)
• maxSupported — เวอร์ชันปัจจุบัน
• คืน maxSupported สำหรับ execution ใหม่, คืนค่าที่บันทึกไว้ตอน replay

ขั้นที่ 1 — เพิ่ม branch ใหม่ โดยเก็บของเก่าไว้#

เคสจริง: ต้องเพิ่มการตรวจ AML ก่อนโอนเงินออก

func WithdrawWorkflow(ctx workflow.Context, req WithdrawRequest) (WithdrawResult, error) {
	actCtx := workflow.WithActivityOptions(ctx, workflow.ActivityOptions{
		StartToCloseTimeout: 60 * time.Second,
	})
	var a *activities.Activities

	if err := workflow.ExecuteActivity(actCtx, a.DebitWallet, req).Get(actCtx, nil); err != nil {
		return WithdrawResult{}, err
	}

	// ธุรกรรมที่เริ่มก่อน deploy นี้ ไม่มี marker → ได้ DefaultVersion → ข้ามการตรวจ
	// ธุรกรรมใหม่ → ได้ 1 → ตรวจ AML
	v := workflow.GetVersion(ctx, "add-aml-screening", workflow.DefaultVersion, 1)
	if v != workflow.DefaultVersion {
		var screening AMLResult
		if err := workflow.ExecuteActivity(actCtx, a.ScreenAML, req).Get(actCtx, &screening); err != nil {
			return WithdrawResult{}, err
		}
		if screening.Blocked {
			return WithdrawResult{}, temporal.NewNonRetryableApplicationError(
				"blocked by AML screening", "AMLBlocked", nil)
		}
	}

	var bankRef string
	if err := workflow.ExecuteActivity(actCtx, a.TransferToBank, req).Get(actCtx, &bankRef); err != nil {
		return WithdrawResult{}, err
	}
	return WithdrawResult{BankRef: bankRef}, nil
}

ขั้นที่ 2 — ลบ branch เก่าหลังของเก่าหมด#

รอจนไม่มี execution ที่ยังใช้ path เก่าเหลืออยู่ ตรวจได้จาก:

temporal workflow list --query \
  'WorkflowType = "WithdrawWorkflow" AND ExecutionStatus = "Running"'

แล้วค่อยยก minSupported ขึ้น:

// เหลือ branch เดียว แต่ยังต้องเก็บบรรทัด GetVersion ไว้
_ = workflow.GetVersion(ctx, "add-aml-screening", 1, 1)

var screening AMLResult
if err := workflow.ExecuteActivity(actCtx, a.ScreenAML, req).Get(actCtx, &screening); err != nil {
	return WithdrawResult{}, err
}

ขั้นที่ 3 — แก้ซ้ำที่จุดเดิม#

v := workflow.GetVersion(ctx, "add-aml-screening", 1, 2)
if v == 1 {
	// ใช้ ScreenAML แบบเดิม
} else {
	// เปลี่ยนไปใช้ vendor ใหม่
}

GetVersion ในลูป#

ค่าที่คืนสำหรับ changeID 1 ตัวจะถูกล็อกไว้ตลอด ถ้าเรียกในลูปโดยใช้ ID เดิม ทุกรอบจะได้ค่าเดียวกันหมด ต้องใส่เลขรอบเข้าไปด้วย

for i, item := range batch {
	v := workflow.GetVersion(ctx, fmt.Sprintf("batch-item-%d", i), workflow.DefaultVersion, 1)
	// ...
}

วิธีที่ 2: Workflow Type ใหม่#

แทนที่จะ patch ให้สร้าง type ใหม่ไปเลย ของเก่ารันจนจบด้วยโค้ดเก่า ของใหม่ใช้โค้ดใหม่

func WithdrawWorkflow(ctx workflow.Context, req WithdrawRequest) (WithdrawResult, error) {
	// v1 — ห้ามแตะ จนกว่าจะไม่มี execution เหลือ
}

func WithdrawWorkflowV2(ctx workflow.Context, req WithdrawRequest) (WithdrawResult, error) {
	// v2 — เขียนใหม่ได้อิสระเต็มที่
}

w.RegisterWorkflow(workflows.WithdrawWorkflow)
w.RegisterWorkflow(workflows.WithdrawWorkflowV2)

แล้วชี้ให้ฝั่ง API เริ่ม execution ใหม่ด้วย WithdrawWorkflowV2

เหมาะกับการรื้อใหญ่ ไม่เหมาะกับการแก้เล็กน้อยบ่อยๆ

วิธีที่ 3: Worker Deployment Versioning#

2 วิธีแรกจัดการเวอร์ชันในโค้ด วิธีนี้จัดการที่ระดับ deployment — ปล่อย worker หลายเวอร์ชันพร้อมกัน แล้วให้ server เป็นคนตัดสินว่า execution ไหนควรไปลงที่เวอร์ชันใด

w := worker.New(c, "wallet-core", worker.Options{
	DeploymentOptions: worker.DeploymentOptions{
		UseVersioning: true,
		Version: worker.WorkerDeploymentVersion{
			DeploymentName: "wallet-service",
			BuildId:        os.Getenv("BUILD_ID"), // git sha หรือเลขเวอร์ชัน
		},
		DefaultVersioningBehavior: workflow.VersioningBehaviorPinned,
	},
})

PINNED กับ AUTO_UPGRADE#

ตั้งรายตัวได้ต่อ workflow เมื่อ default ไม่เหมาะ:

// ธุรกรรมเติมเงินสั้น — pin ไว้เลย
w.RegisterWorkflowWithOptions(workflows.TopUpWorkflow, workflow.RegisterOptions{
	VersioningBehavior: workflow.VersioningBehaviorPinned,
})

// Entity workflow ของบัญชี wallet อยู่ยาวเป็นปี pin ไม่ได้
w.RegisterWorkflowWithOptions(workflows.WalletAccountWorkflow, workflow.RegisterOptions{
	VersioningBehavior: workflow.VersioningBehaviorAutoUpgrade,
})

เปลี่ยนเวอร์ชันปัจจุบัน#

# ดูสถานะ deployment
temporal worker deployment describe --deployment-name wallet-service

# ปล่อยทีละน้อยก่อน (canary) — ส่ง execution ใหม่ไปเวอร์ชันใหม่บางส่วน
temporal worker deployment set-ramping-version \
  --deployment-name wallet-service \
  --build-id v2.0.0 \
  --percentage 5

# พอใจแล้วค่อยสลับทั้งหมด
temporal worker deployment set-current-version \
  --deployment-name wallet-service \
  --build-id v2.0.0

ข้อดีที่สำคัญที่สุดสำหรับระบบการเงินคือ rollback ทำได้ทันที — สั่ง set-current-version กลับไปที่ build เดิม execution ใหม่ก็ไหลกลับไปเวอร์ชันเก่า โดยไม่ต้อง deploy โค้ดใหม่

temporal workflow list --query \
  'TemporalWorkerDeploymentVersion = "wallet-service:v1.0.0" AND ExecutionStatus = "Running"'

ใช้คำสั่งนี้ดูว่ายังมีใครค้างอยู่บนเวอร์ชันเก่าไหม ก่อนจะปิด worker เก่า

เลือกวิธีไหนดี#

System map

ในทางปฏิบัติของระบบ wallet มักใช้ผสมกัน:

• ธุรกรรมสั้น (top-up, withdraw) → Worker Versioning แบบ PINNED
• Entity workflow ของบัญชี → AUTO_UPGRADE + GetVersion ทุกครั้งที่แก้
• รื้อ flow ใหม่ทั้งหมด → Workflow Type ใหม่

ขั้นตอน deploy ที่ปลอดภัย#

1. ตัดสินก่อนว่าการแก้นี้ breaking ไหม — ถ้าไม่แน่ใจ ให้ถือว่า breaking
2. รัน replay test กับ fixture ทุกไฟล์ (บทที่ 9) — ต้องผ่านทั้งหมด
3. ถ้าใช้ GetVersion ให้เพิ่ม fixture ของ path ใหม่เข้า testdata ด้วย
4. Deploy worker ใหม่โดยยังไม่ปิด worker เก่า
5. ดู metric temporal_workflow_task_execution_failed ว่าไม่พุ่ง (ดูบทที่ 11)
6. ตรวจ execution ที่ค้างบนเวอร์ชันเก่าด้วย temporal workflow list
7. ปิด worker เก่าเมื่อไม่มี execution เหลือ