Introduction to Temporal#

Temporal is a durable execution engine. You write workflows as ordinary code – if/else, loops, function calls – and Temporal guarantees that code runs to completion even when processes crash, machines fail, or deployments happen mid-execution. It eliminates the need to build retry logic, state machines, and recovery mechanisms by hand.

This article introduces the core concepts, architecture, and use cases. It is the first in a series that takes you from zero to running production workflows on Kubernetes.

Multi-Stage Temporal Workflows#

The HelloWorkflow from Temporal Go Workflow Basics calls one activity and returns. Real workflows are not that simple. A deployment pipeline provisions infrastructure, configures networking, deploys the application, runs health checks, and updates DNS. Each step depends on the previous one. Any step can fail. Some failures require undoing earlier steps.

This article covers the patterns you need for production multi-stage workflows: sequential activities with data passing, retry policies, timeouts, child workflows, error propagation, and compensation.

Git Branching Strategies#

Choosing a branching strategy is choosing your team’s speed limit. The wrong model introduces merge conflicts, stale branches, and release bottlenecks. The right model depends on how you deploy, how big your team is, and how much you trust your test suite.

Trunk-Based Development#

Everyone commits to main (or very short-lived branches that merge within hours). No long-running feature branches. No develop branch. No release branches unless you need to patch old versions.

GitHub Actions Fundamentals#

GitHub Actions is CI/CD built into GitHub. Workflows are YAML files in .github/workflows/. They run on GitHub-hosted or self-hosted machines in response to repository events. No external CI server required.

Workflow File Structure#

Every workflow has three levels: workflow (triggers and config), jobs (parallel units of work), and steps (sequential commands within a job).

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.23'
      - run: go test ./...

  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: golangci/golangci-lint-action@v6

Jobs run in parallel by default. Steps within a job run sequentially. Each job gets a fresh runner – no state carries over between jobs unless you explicitly pass it via artifacts or outputs.