Kate's Blog

subtitle

發表於 更新於 分類於

用 Gitea Actions 打造你的 CI/CD 自動化流程 🚀

這篇文章將帶你一步步用 Gitea Actions 打造自己的自動部署流程，從安裝 Runner 到實作 workflow，不只是跑測試，還能部署 Docker 應用。

為什麼選 Gitea Actions？🤔

我選擇它的幾個原因：

  • ✅ 自架、開源、輕量，不依賴 GitHub.com
  • ✅ 支援 GitHub Actions 的語法，相容度高
  • ✅ 跟 Gitea repository 整合超順，原生支援 PR trigger
  • ✅ 社群活躍，仍持續更新（2025 年開始加入 matrix 策略等進階特性）

前置準備 🧰

1️⃣ 安裝 Gitea Actions Runner

1
2
3
curl -s https://dl.gitea.com/act_runner/latest | bash
chmod +x act_runner
./act_runner register

註冊過程會問你 Gitea server 的網址、Access Token、repository 等資訊。完成後會自動產生 ~/.act_runner/ 配置檔，然後就能啟動 runner：

1
./act_runner daemon &

📌 避坑提醒：

  • Token 必須有 actions:write 權限

  • 如果你是 root 使用者安裝，請留意目錄權限問題，建議建立專用 ciuser

設定 CI/CD 工作流程（workflow）

在你的 repository 裡建立 .gitea/workflows/ci.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
name: Build and Deploy

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Run Unit Test
        run: |
          npm install
          npm test

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy via Docker Compose
        run: |
          docker compose -f docker-compose.prod.yml up -d --build

✅ 這段流程做了三件事：

  1. Pull 你的程式碼
  2. 安裝與執行測試
  3. 測試通過後，自動部署 Docker 版本到正式機

配合 .env 與 Volume 管理你的部署設定

我會這樣設計 docker-compose.prod.yml：

1
2
3
4
5
6
7
8
9
services:
  web:
    build: .
    image: myapp:latest
    env_file: .env.prod
    ports:
      - "80:3000"
    volumes:
      - ./data:/app/data

📌 實務建議：

  • 使用 .env.prod 分離環境參數
  • 將部署流程分開維護（ci.yml 不要直接包含敏感參數）

實戰部署與整合體驗

我把這套流程整合進我自己的專案後，每次 push 到 main 分支，就會：

  • 自動執行測試
  • 成功後觸發部署
  • 若失敗則不更新正式環境（避免髒 build）

🚨 避坑提醒：

  • 若你在 deploy 階段用了 docker compose down && up，要確保 volume 資料別被砍掉！
  • 測試與正式機若共用 Runner，記得使用 –project-name 隔離工作目錄

發表於 分類於

如何在社群上和大神合作?

我自己在寫 side project 或是參與多人協作時，發現了 GitHub Flow 的重要性。它讓我在處理分支、同步進度、合併改動時比較不容易踩雷。

誠心推薦的教學影片：十分钟学会正确的 GitHub 工作流

前言

GitHub Flow 是一套非常實用的流程：

  1. 為每個功能建立分支
  2. 本地提交並推送到 GitHub
  3. 與 main 分支保持同步（rebase）
  4. 發起 Pull Request，進行 code review
  5. 使用 squash and merge 合併
  6. 刪除分支，保持倉庫整潔

步驟一: 建立功能分支

1
git checkout -b feature/awesome-update

在 main 上開發是禁忌。先從 main 切出分支再動手，不管是新增功能還是修 Bug，都要獨立開發、獨立測試，這樣出問題才不會拖垮整個專案。

步驟二: 編輯、提交、檢查差異

修改完代碼之後，記得：

1
2
3
git diff
git add .
git commit -m "feat: add awesome update"

養成 good commit message 的習慣，後面回頭看的時候會感謝自己。建議在提交前用 git diff 看一下，確保不小心加了 debug 或多餘的修改。

步驟三: 與 main 同步，保持乾淨提交歷史

功能開發不會在真空中進行。main 分支的進度可能已經更新，我們要透過 rebase 整合最新的變更：

1
2
git fetch origin
git rebase origin/main

rebase 會讓提交記錄保持線性，是 GitHub Flow 推薦的做法。若出現衝突，就手動解、git rebase --continue。

步驟四: 發起 Pull Request（PR）

當功能開發完成後，推上 GitHub：

1
git push origin feature/awesome-update

進到 GitHub 倉庫，發起 Pull Request，指明要合併到 main。在 PR 裡可以：

  • tag reviewer（協作者）
  • 解釋變更動機與內容
  • 附上截圖或測試方式

步驟五: 使用 Squash and Merge 合併

PR 通過後，請選擇 Squash and Merge 而不是 Merge commit：

✅ 優點：

  • 合併進 main 時只留下 1 筆 commit，保持簡潔歷史
  • 雜亂的小 commit 不會污染主線

合併後記得：

1
2
git branch -d feature/awesome-update
git push origin --delete feature/awesome-update

發表於 更新於 分類於

前言

我不是維運工程師，但我希望自己開發的系統能夠：

  1. 在用戶發現問題之前，先自己發現並處理
  2. 出錯時能快速排查，不靠 *.log 苦力 grep
  3. 平時能留下資料，未來好做統計與系統評估

這篇文章會分享我怎麼將開源工具整合進我的系統：
使用 Filebeat、Logstash、Elasticsearch、Kibana（簡稱 ELK），快速搭出一套後端 log 監控架構。
不靠複雜 infra，全程用 Docker Compose 一鍵啟動。
📦 完整 docker-compose.yml 放這裡 👉 GitHub Repo

Quick Start

架構概覽：Fastify + ELK Flow

1
2
3
4
5
6
7
8
9
Fastify（logs/*.log）
  ↓
Filebeat：收集 log，JSON native 支援佳
  ↓
Logstash：欄位分類、格式轉換、前處理
  ↓
Elasticsearch：儲存與查詢，支援自動分日索引
  ↓
Kibana：查詢 & 圖表視覺化介面

事前準備：Fastify 寫入 JSON Log

我在 Fastify 專案中使用 Winston，把每次 API 請求都記錄成 JSON 格式的 log 檔案，方便後續被 ELK 收集與分析。

📁 log 檔案目錄範例如下：

1
2
/fastify_deploy/logs/
├── api-access.log        # 每筆 API 請求

📝 實際 log 範例（每行為一筆 JSON）：

1
[2025-05-23 08:15:24] INFO: {"timestamp":"2025-05-23T08:15:24.215Z","method":"POST","url":"/api/v1/auth/login","status":200,"duration":297,"user_id":"guest","ip":"172.18.0.1"}

設定整合：讓 Log 自動進入 ELK

所有服務都跑在 Docker 容器中，而 Fastify 寫出的 log 則透過 volume 掛載到 Filebeat。(如 Repo 所示之 dev-compose.yml)
並在啟用前，建立ELK所需設定檔。(如下所示)

📂 檔案結構（dev-compose.yml目錄下）：

1
2
3
4
5
6
.
├── filebeat/
│   └── filebeat.yml # 輸出設定
├── logstash/
│   └── pipeline/
│       └── logstash.conf # 解析規則

📄 filebeat/filebeat.yml 範例：

1
2
3
4
5
6
7
filebeat.inputs:
  - type: log
    paths:
      - /logs/*.log # 掛載 fastify log 的 volume 路徑

output.logstash:
  hosts: ["logstash:5044"] # 指向 logstash 容器

📄 logstash/pipeline/logstash.conf 範例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
input {
  beats {
    port => 5044
  }
}

filter {
  json {
    source => "message"
    skip_on_invalid_json => true
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "fastify-logs-%{+YYYY.MM.dd}"
  }
}

啟用

建立完上述資料夾與設定檔後，執行：

1
docker compose up -d

然後開啟瀏覽器進入：

1
http://localhost:5601

到 Kibana 建立 index pattern，例如：

1
fastify-logs-*

成果

🔍 查詢錯誤：type: api AND status: 500
🔎 篩選路徑：url: /api/v1/auth/login
📊 觀看圖表報表：

  • Top 5 最常被打的 API
  • status 401 的來源 IP 統計
  • 最近 30 分鐘錯誤數趨勢

發表於 更新於 分類於

API 是最後防線，後端驗證不是加分項

曾經我在 PR 裡加入了 MAC Address 與 Serial Number 的格式驗證，卻被視為「應該交由前端處理」而被移除。但後端驗證從來不是錦上添花，而是守住系統邏輯與安全底線的責任。

在前後端分離的開發架構中，前端確實適合處理表單提示與使用者互動，但資料是否可信、格式是否正確，最終仍需由後端把關。這不只是風格問題，而是攸關資料正確性與系統安全的底線。

為什麼不能只靠前端驗證？

  • 攻擊者可繞過前端，直接對 API 發送請求，不受前端約束。
  • 前端驗證容易遺漏，稍有改版就可能忘記檢查邊界狀況。
  • 資料庫的品質與安全性，只能靠後端確保。

不論你多信任使用者或自己的 UI，一旦 API 對外開放，所有輸入都應視為不可信，直到經過後端驗證為止。

常見卻易忽略的驗證需求

欄位類型 常見問題 建議處理方式
MAC Address 大小寫混用、缺冒號、格式不符 正規化格式、統一轉小寫
Serial Number 空白、特殊符號、長度不一 去除多餘空白、限制長度與字元集
Email 格式錯誤、大小寫比對錯誤 標準格式驗證、轉小寫比對
Phone Number 國碼遺漏、格式不統一 統一格式、清理非數字字元
自由輸入文字 可注入 <script> 等惡意內容 過濾 HTML 標籤與特殊字元
JSON 結構欄位 欄位未定義、型別錯誤 僅允許白名單欄位、進行深層驗證
可變長欄位 無長度限制、可被用來進行 DoS 攻擊 設定合理最大長度

後端若不進行上述驗證，可能會導致資料一致性問題、系統崩潰、甚至資安事件。

格式驗證是後端的基本責任

有些人認為「後端只要處理業務邏輯，格式交給前端就好」，但這種分工方式忽略了一個事實：API 是唯一直接接觸資料庫的接口，也是攻擊者的主要進入點。

後端若不主動驗證與保護，資料庫很快就會被寫滿錯誤、污染甚至惡意資料。屆時處理成本會比一開始做好驗證高上數倍。

結語：驗證不是「多做」，而是該做

後端驗證不是在跟前端搶工作，也不是完美主義者的堅持，而是為了讓系統穩定、安全、可維護。

請不要再說「這應該交給前端處理」了。格式驗證、大小寫正規化、欄位清洗，本來就是後端應做的基本工事。既然 API 是最後一道防線，就該由後端守住，而不是放行。

發表於 更新於 分類於

只要你還讓 Dev、Test、Staging 混在同一台機器上，就不會有真正可驗證的交付流程。

測試會失效、整合會混亂、問題無法重現，所有角色彼此踩線，流程變成推責任的戰場。這不是 infra 的問題，而是團隊紀律的問題。

Respect the flow 不是形式，而是一種責任感 —— 對於環境分層、版本凍結、角色邊界的基本尊重。

每個環境都有該扮演的角色

軟體開發流程中，常見的四個環境層級與實體建議如下：

  • Development：自由開發、頻繁變動（如在本地機器或 sandbox VM）
  • Testing：功能驗證、壓力測試（如地端共用測試主機）
  • Staging：驗收整合、模擬實際部署（如雲端與 Prod 同規格的 VM_1）
  • Production：穩定服務、對外公開（如雲端正式環境 VM_2）

每個環境都應對應獨立部署單元或主機，避免如下常見錯誤：

  • test server 被 RD-Team 當作開發環境直接使用
  • staging server 被拿來跑 測試流程
  • develop 分支還在 push，測試團隊已經在執行驗證

一旦角色模糊，整個流程就會失去可追溯性與穩定性。

如果你不 freeze，下游就會 freeze 住

最典型的情況是：

「前端 在串 test server 上的後端，突然工作被中斷，因為 API 斷線了，然後原本有些欄位一下出現又一下不見…因為後端還在那上面改寫。」

「Test-Team 在 test server 上測試，突然 WEB 斷線了，然後原本有些按鈕功能一下出現又一下不見…因為前/後端還在那上面改寫。」

這會造成：

  • 前端 工作被中斷
  • 前端 整合反覆修改、重構
  • 測試人員 無法重現 bug、流程斷鏈
  • 測試結果無效，驗證版本與實際版本不一致

測試不是幫你 debug，而是驗證一個凍結版本能否穩定上線。

測試是驗收場，Staging 是最後防線，不是跳板

測試環境的存在，是為了讓團隊能在明確版本的基礎上進行以下驗證行為：

  • 前端 對接穩定的 後端 (API / Schema)
  • Test-Team 驗證功能與流程正確性
  • Test-Team 進行壓力測試、功能巡檢
  • PM-Team 做出上線前的確認與取捨

這些前提都建立在一個基本共識上：這台機器上的版本不會變。
一旦允許後端隨意 push、改資料結構或重啟服務，這個環境就失去了所有驗證意義。

但光有 test server 還不夠 —— staging 應該存在，並且與 production 一致（或幾乎一致），讓團隊能在上線前模擬實戰，驗證部署流程與設定變數，找出遺漏與風險。

如果沒有 staging，等於你是在開發測一半、就直接蓋上正式環境。這不叫快速交付，這叫賭博。

test server 是為了驗證功能正確，
staging server 是為了驗證部署正確。

兩者都不能省，否則你永遠不知道你測的是什麼、上的是什麼。

Respect the Flow，就是尊重邊界與責任

CI/CD 再強大，也沒辦法替你維護流程紀律。
Git 分支再清晰，也撐不住你把所有環境塞在一台 VM 上亂部署。

你可以開發得快，但你不能亂；
你可以 iterate 常常 push，但你不能 push 到別人腳下。

一個乾淨的交付流程需要：

  • 明確的環境邊界：dev、test、staging、prod 不可混用
  • 固定的版本控制：release 分支一旦部署到 test，就不得更動
  • 乾淨的部署紀律：不同環境對應不同 tag 或 commit
  • 穩定的整合基礎：測試與前端整合皆依據可重現版本進行

這些不是為了形式化流程，而是為了讓開發不會踩到測試、測試不會受制於開發、整合能放心進行、責任能夠明確釐清。

小結：流程是一種信任協議

流程之所以重要，是因為它讓責任可追、溝通可簡、節奏可持續。

你可以用最快速度開發，但不能讓這種速度成為其他人的成本。
Respect the Flow，代表你願意為「穩定的交付」負責，而不只是寫完一段功能就結束了。
這是工程紀律，也是職業態度。

Respect the flow — don’t test on dev, don’t dev on test.

發表於 更新於 分類於

使用 Fastify、Sequelize 和 JWT 實現 RBAC 權限管理

在這篇文章中，我將分享如何使用 Fastify、Sequelize 和 JWT 搭建一個後端架構，並且通過 RBAC（基於角色的訪問控制） 來管理用戶的訪問權限。這些技術的組合讓我們能夠快速且安全地處理用戶身份認證與角色管理，並確保 API 的安全性。

為何選擇這些技術？

  • Fastify：這是一個高效且易於擴展的 Node.js 框架，提供了強大的性能和極為簡單的 API 設計，能夠輕鬆應對高並發的請求。

  • Sequelize：作為一個強大的 ORM 工具，Sequelize 可以簡化與資料庫的交互，並且支持多種關聯型資料庫，適合用來處理用戶資料和角色資料。

  • JWT：JWT 是一種輕量級的身份驗證機制，可以在不同服務之間安全地傳遞用戶的身份信息，並且能夠實現無狀態的認證系統。

如何實現 RBAC（基於角色的訪問控制）

  1. 設定資料模型
    首先，我們需要設計 User 和 Role 模型，並使用 Sequelize 來管理這些資料。每個用戶都會被分配一個角色，角色則定義了用戶可以訪問的資源。
  2. 設定角色和權限
    我們使用 AccessControl 库來設定每個角色可以執行的操作。例如，groupViewer 角色只能讀取資料，而 groupManager 則擁有更多的操作權限。
  3. 中間件：基於角色的授權
    為了保證每個用戶只能訪問他們被授予權限的資源，我們在 Fastify 中創建了一個名為 authorize 的中間件，來進行每次請求的授權檢查。
  4. 設定 JWT 認證
    用戶登錄後，系統會發送一個 JWT 令牌，這個令牌會包含用戶的角色信息。在後續的 API 請求中，我們會驗證 JWT，並根據角色來授權。

使用 JWT 和 RBAC 進行授權操作

一旦用戶成功登錄並獲得 JWT，後端可以根據用戶角色來授權操作。例如，讓 groupManager 角色的用戶將某個用戶分配到某個組織並賦予相應的角色。

分配用戶到某個組織並賦予角色：
在這個 API 中，我們會驗證用戶的角色，然後根據角色授予其相應的權限。假設我們要實現將用戶分配到某個組織並賦予角色的功能，這樣的 API 需要確保只有 groupManager 和 groupAdmin 角色能夠進行此操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
fastify.post('/assign-user-role', { preValidation: [fastify.authorize('createAny', 'userRole')] }, async (request, reply) => {
  const { userId, organizationId, roleId } = request.body;

  // 確認用戶是否已經存在
  const user = await User.findByPk(userId);
  if (!user) {
    return reply.code(404).send({ error: 'User not found' });
  }

  // 分配角色
  const userRole = await UserRole.create({
    user_id: userId,
    organization_id: organizationId,
    role_id: roleId
  });

  return reply.code(200).send({ message: 'User role assigned successfully', userRole });
});

小結

這篇文章介紹了如何使用 Fastify、Sequelize 和 JWT 實現一個帶有 RBAC（基於角色的訪問控制）的後端架構。通過簡單的程式範例，我們展示了如何設定角色和權限，並且使用 JWT 來進行用戶身份驗證和授權操作。這個架構簡單且高效，適合用於需要角色管理和精細化權限控制的應用。

如果你有興趣查看具體的程式碼實現，可以前往我的 GitHub 相關專案：https://github.com/kk034kk034/management-system

發表於 更新於 分類於

前言

純軟的軟體工程師
通常大家拿到的電腦應該都是Windows居多
但開發環境還是使用linux比較順手的情況下
以下是我常用的環境與工具

Quick Start

STEP 1:
搜尋: 開啟或關閉 Windows 功能
勾選: Windows 子系統 Linux 版(有Hyper-V的話也有勾選)
確定->等待->立即重新啟動

STEP 2:
於 Microsoft Store 裡搜尋並安裝 Ubuntu
安裝完啟動，會要輸入(設定)帳號與密碼

STEP 3:
在系統管理員模式中開啟 PowerShell，輸入以下命令

1
2
wsl --install #通常目前下載就已經是WSL2了
wsl --set-default-version 2 #如果不是的話就將WSL預設版本調成WSL2

STEP 4:
安裝與設定Docker Desktop

STEP 5:
安裝與使用MobaXterm

STEP 6:
安裝與使用VS Code and/or Cursor

發表於 更新於 分類於

新創必備 - Slack 高效溝通指南

Slack 作為全球新創公司的溝通利器，不只是聊天工具，更是提升團隊生產力和創造協作氛圍的重要平台。以下，我們將介紹如何善用 Slack，以及新創團隊在使用中不可不知的技巧與避坑經驗。

Slack 的關鍵優勢

  1. 集中化的團隊溝通：以頻道（Channel）為單位組織討論，避免重要資訊埋沒在私訊裡。
  2. 無縫整合工具：可與 Google Drive、Trello、Jira 等工具連接，輕鬆導入工作流程。
  3. 強大的搜尋功能：歷史訊息、檔案共享一鍵即達，不怕漏掉任何細節。
  4. 彈性通知設定：根據需要自訂通知，保持專注且不被打擾。

頻道管理技巧

必備頻道設置建議

  • 基礎頻道
    • #announcements：重要公告、政策變更
    • #watercooler：非正式交流，建立團隊文化
  • 專案頻道
    為每個專案建立專屬頻道，如：#project-xyz
  • 功能型頻道
    • #help-it：IT 支援與技術問題解答
    • #feedback：用戶或內部回饋收集

頻道命名最佳實踐

  • 格式：[分類]-[內容]，如 team-frontend 或 project-launch
  • 範圍明確：避免大雜燴頻道，確保每個頻道討論目標明確。

實用技巧與避坑建議

  1. 善用線程（Threads）
    避免長篇對話占滿頻道。所有回應統一用線程，保持主頻道清爽、聚焦。

    避坑提醒：過多的線程回覆會讓訊息難以察覺。對重要回覆，記得用表情符號（Emoji）標記主訊息。

  2. 表情符號不只是「表情」
    Slack 的 Emoji 功能遠超你想像，以下是一些高效應用：
    ✅ 已處理
    ❓ 需要澄清
    👀 正在查看
    🚀 已完成

    避坑提醒：不要使用過於模糊的表情，確保團隊理解統一。

  3. 整合工具，簡化流程
    Slack 的真正威力來自它的整合能力：

    • 專案管理：結合 Trello，新增任務或更新進度。
    • 文件共享：Google Drive 提醒與授權直接在 Slack 完成。
    • 錯誤追蹤：Jira Bot 自動提醒 Bug 狀態更新。

    避坑提醒：整合過多工具可能導致通知轟炸，請謹慎設置通知規則。

  4. 高效訊息格式

  • 緊急通知：🚨 [緊急]

    範例：🚨 [緊急] 伺服器無法連線，需工程團隊協助。

  • 重要回顧：📌 [會議記錄]

    範例：📌 [會議記錄] 週會討論重點已上傳至 Google Drive。

  • 一般討論：用開頭標籤簡化分類，像 [求助]、[建議]。

  1. 設定智能通知
  • 核心頻道通知永遠開啟：如 #team-product。
  • 次要頻道開關通知：設置為僅關鍵字提醒（如 “deadline” 或 “urgent”）。
  • 設定「勿擾模式」：自動告知對方目前狀態，避免無意干擾。

檔案與訊息管理秘訣

  • 命名格式統一
    如：[團隊名稱]-[檔案類型]-[日期]，方便搜尋。

    範例：design-mockup-20241124.png

  • 過時資訊清理
    每月固定整理頻道的舊訊息與檔案，避免占用空間。

  • 重要內容書籤化
    使用 Slack 的書籤功能（Pin）標記頻道中不可遺漏的訊息。

真實使用心得與成功案例

  1. 透明化決策
    某團隊透過 Slack 頻道公開所有會議記錄與討論，讓全體成員清楚決策過程，提升信任與效率。

  2. 敏捷開發支持
    工程團隊在專案頻道中整合 GitHub 和 CI/CD 工具，實現即時部署通知，大幅縮短回應時間。

  3. 打造歸屬感
    定期舉辦「Slack 傳情活動」，利用 Emoji 投票或 GIF 分享，促進跨部門互動。

結語：Slack 是新創文化的延伸

Slack 的力量在於它能幫助團隊打造高效、開放且友善的工作環境。但要真正發揮它的潛力，依賴的不只是功能，而是對工具的理解與文化的實踐。

現在就從優化你的 Slack 開始，讓它成為新創成功的秘密武器！

發表於 更新於 分類於

新創必備 - Jira專案管理工具

在現代科技新創公司中，有效的專案管理工具對於確保產品開發的順利進行至關重要，特別是在遠端工作和前後端分離的開發模式下。本文將深入介紹如何設置和運用Jira來提升團隊協作效率。

為什麼選擇Jira？

Jira作為業界領先的專案管理工具，具有以下優勢：

  • 完整支援Scrum和Kanban等敏捷開發方法
  • 強大的工作流程自定義能力
  • 豐富的第三方工具整合選項
  • 完善的報告和分析功能
  • 適合分散式團隊協作

基礎設置指南

1. 項目結構規劃

  • 建立適合團隊規模的項目架構
    • 小團隊（10人以下）：單一項目即可
    • 大團隊：可按功能模組或團隊分割項目

2. Sprint週期設定

  • 建議新團隊採用2週衝刺
    • 第一週五：Sprint規劃會議
    • 每日15分鐘站會
    • 最後一天：Sprint回顧會議

3. Kanban板配置

  • 標準工作流程欄位：
    • Backlog（需求池）
    • To Do（待處理）
    • In Progress（進行中）
    • Code Review（程式碼審查）
    • QA Testing（測試中）
    • Done（完成）

核心功能配置

1. Issue類型設置

  • Epic：大型功能集合，跨越多個Sprint
  • Story：用戶故事，描述具體功能需求
  • Task：技術任務，可直接執行
  • Bug：問題修復

2. 優先級定義

  • Highest：影響核心功能的緊急問題
  • High：重要功能開發
  • Medium：一般功能開發
  • Low：優化類任務

工作流程自動化

1. 版本控制整合

  • 配置GitHub/Bitbucket整合
    • 提交訊息關聯Issue
    • PR自動更新Issue狀態
    • 程式碼審查追蹤

2. 自動化規則設置

  • 常用自動化規則：
    • PR合併後自動移動Issue至Done
    • 新Bug自動通知相關開發者
    • Sprint即將結束自動提醒

遠端協作最佳實踐

1. 文件整合

  • 使用Confluence作為知識庫
    • 技術文檔
    • 會議記錄
    • 產品規劃
    • 開發規範

2. 通訊整合

  • 配置Slack通知
    • Issue更新提醒
    • Sprint開始/結束通知
    • 重要里程碑提醒

3. 移動端支援

  • 安裝Jira移動應用
    • 隨時查看任務狀態
    • 快速更新進度
    • 即時回應評論

結論：Jira的正確配置能大幅提升團隊協作效率，特別適合新創公司快速迭代的開發模式。關鍵在於根據團隊實際需求進行合理配置，並持續優化工作流程。

發表於 更新於 分類於

新創必備 - 在 Raspberry Pi 上部署 GitLab CE

  • Build Own VCS, GitLab
  • Community Edition(CE) is Free
  • Deploy on Raspberry Pi is Easy and Cost Down
  • gitlab.rb is Flexibility

Quick Start

安裝方式分成兩種，一種是直接安裝，另一種是docker版(建議)。
我是樹莓派4B，所以是安裝arm64v8的版本。

直接安裝

下載deb檔案

1
2
$ sudo dpkg -i gitlab-ce_8.13.0-ce.0_armhf.deb
$ sudo gitlab-ctl reconfigure

初始默認的port是80，若有需要改port，就修改/etc/gitlab/gitlab.rb裡面的external_url及其nginx[‘listen_port’]，例如想改成8080。

1
2
3
4
5
6
$ sudo vi /etc/gitlab/gitlab.rb
i
external_url 'http://your-ip:8080'
nginx['listen_port'] = 8080
:qw
$ sudo gitlab-ctl reconfigure

docker版安裝

GitLab-ce docker image builder for arm64v8

1
$ sudo docker pull yrzr/gitlab-ce-arm64v8:latest
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
docker run \
  --detach \
  --restart unless-stopped \
  --name gitlab-ce \
  --privileged \
  --memory 8G \
  --publish 22:22 \
  --publish 80:80 \
  --publish 443:443 \
  --hostname gitlab.example.com \
  --env GITLAB_ROOT_PASSWORD="YourPasswordHere" \
  --env GITLAB_OMNIBUS_CONFIG=" \
    registry['enable'] = false; \
    GITLAB_OMNIBUS[your_other_configs] = `options`; "\
  --volume /srv/gitlab-ce/conf:/etc/gitlab:z \
  --volume /srv/gitlab-ce/logs:/var/log/gitlab:z \
  --volume /srv/gitlab-ce/data:/var/opt/gitlab:z \
  yrzr/gitlab-ce-arm64v8:latest

或我建議是用docker-compose.yml做，因為未來可能還有其他服務可以寫在一起管

1
$ vi docker-compose.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
version: '3'
services:
  gitlab:
    image: yrzr/gitlab-ce-arm64v8:latest
    container_name: gitlab
    restart: always
    privileged: true
    environment:
      TZ: 'Asia/Taipei'
      GITLAB_OMNIBUS_CONFIG: |
        external_url = "http://your-ip"
        gitlab_rails['time_zone'] = 'Asia/Taipei'
#        gitlab_rails['gitlab_ssh_host'] = 'your-ip'
#        gitlab_rails['gitlab_shell_ssh_port'] = 2222
    ports:
      - '80:80'
      - '443:443'
#      - '2222:22'
    volumes:
      - '/home/pi/docker-gitlab/config:/etc/gitlab'
      - '/home/pi/docker-gitlab/logs:/var/log/gitlab'
      - '/home/pi/docker-gitlab/data:/var/opt/gitlab'
    logging:
      driver: "json-file"
      options:
        max-size: "20m"
        max-file: "10"
1
$ sudo docker-compose up -d

我大概等了十分鐘能連上 http://your-ip:80 ，初次啟動的帳戶是root，密碼要到/etc/gitlab/initial_root_password看，然後用這個密碼登入，之後就可以改密碼了。

1
$ sudo docker exec -it gitlab grep 'Password:' /etc/gitlab/initial_root_password

其他指令也都是要藉由docker exec進去執行，例如

1
$ sudo docker exec -it gitlab gitlab-ctl status
0%