HowTo-Redmine 整合 Git/GitHub

目的:

讓 Redmine 可以瀏覽位於遠端 Git Server 如 GitHub 儲庫每一次的提交 (commit)歷史資訊,並能達成 Redmine 的 Issue 與 Git Commit 關聯。

說明:

Redmine 僅能讀取位於 local 端的儲庫 (repository)內容,卻沒有支援透過 Git 協定連結位於遠端 Git Server 上的儲庫。

主要解決方案就是先在 local 端建立對遠端儲庫的鏡射 (mirror),然後透過以下三種方式之一:

  1. 建立批次檔,內容為可以提取更新遠端的儲庫內容 (ex. git fetch -q --all)並設定定期執行作業 (ex. cron)。可以參考此篇-HowTo keep in sync your git repository for redmine
  2. 在 GitHub 上所欲讀取的儲庫專案,在其設定 → Service Hooks 上啟動 Redmine,輸入包括 Remine 所在 Url、專案名稱、API Keys 等欄位資訊,並勾選相關執行選項。可以參考此篇-HowTo simply keep Redmine in sync with GitHub
  3. 在 Redmine 所在位置安裝 Redmine GitHub Hook plugin,並於 GitHub 上該儲庫專案新增一個 WebHook URL,填入 Remine 專案所在 Url 位置,由 GitHub 連結 Remine。

第一種方式最簡單,但並不自然,因為 Remine 所在機器需定期執行遠端儲庫更新作業,即使遠端儲庫內容並未更新;第二與第三種方式是屬於 publish-observe 合理的作法,當遠端儲庫 (GitHub)的內容被更新時,它會透過 service hook (擔任 event-handler)轉呼叫位於 Redmine local 端的儲庫來更新內容。

第二種方式的 service hook 是由 GitHub 這邊所提供的,Remine 並不需要安裝額外的 plugin。但我設定嘗試了好幾次卻無法達成更新 Redmine 所在儲庫內容,所以我這裡是採用第三種方式,由 Redmine 這裡提供 github hook plugin,再至 Github 設定 WebHook Url,透過 Web Service 達成兩端的同步。

實作步驟 -

閱讀全文 »

HowTo-安裝 Redmine 2.3.2@EC2-Ubuntu 12.04

關於如何申請 Amazon EC2 Free Tier (第一年免費),可以參考此篇-快速安裝 Amazon EC2 LAMP 環境 (EC2 Console)Amazon AWS EC2 LAMP Quickstart Guide

在創建 instance 時,我安裝的 OS 是預設的 Ubuntu LTS 12.04 64-bit (AMI ID: ami-70f96e40),伺服器地區為 US West (Oregon),選擇的方案當然是免費的 T1 Micro (630Mb RAM) Free Usage Tier,這僅對架設小型站台 (如 Redmine 等 Issue Tracking 系統)已是足夠了。

除了 Ubuntu 作業系統外,包括 AMP (Apache, MySQL, PHP), Git, Ruby, redmine 等,全都是需要透過 Putty 連線至 EC2 Console 安裝設定的 (當然,也要先設定好如何遠端連線)。千萬不要安裝 X-Windows 環境於 EC2,我曾試過,然後可以利用 FreeNX 透過 RDP 遠端遙控 EC2,但主記憶體吃了 580Mb,僅剩 10Mb 可茲利用 (有效記憶體僅為 590 Mb)。

至於為何不乾脆使用 BitNami Redmine Cloud Server,或直接安裝 BitNami Redmine Stack AMI (Amazon Machine Image) 映像檔就可以直接使用?因為沒有免費的糖果啦!直接使用 Bitnami Redmine Stack,每個月的租費至少需要 US$15,那就是買你懶得或不諳系統安裝的使用者的系統建置服務費的。為了省錢同時也練習一下關於 Linux 相關系統建置,一切還是自己來。

Redmine 是一套近兩年頗為歡迎的專案管理工具,可以參考此篇-Redmine 基本功能介紹。Remine 支援絕大宗的版控系統 (包括 Git, Subversion, CVS 等),使得更輕易整合關於 Issue 與 Commit 訊息。

Redmine 是使用 Ruby on Rails Framework 撰寫開發的系統,所以作業系統需要具有可執行 Ruby 的直譯環境,當然也需要有 Web Server (支持 Apache, Nginx) 與 資料庫系統 (支持 MySQL, PostgreSQL),才可以完整運作 Redmine。

這裡列出包括作業系統與所需要建置的應用系統:
 o Ubuntu LTS 12.04 64-bit。
 o Apache 2.2。
 o MySQL 5。
 o Ruby 1.9.3 (使用 RVM 安裝)。
 o Redmine 2.3.2 (2013-07-14)。

閱讀全文 »

初識 Git∣GitHub-關於版本控制

關於版本控管

版本控制 (version control),係針對電子化的檔案,包括文件 (document)、程式碼 (source code)、與其它需被整理保存的資訊等,對其變動情形作有效的追蹤管理。

對於軟體開發過程,軟體開發者利用版本控制來追蹤、維護程式碼、設計文件、設定檔等變動情形;尤其是當面臨多人協同開發時,相關設計的文檔必然會複製多份版本分散置於每一位開發人員的電腦內,只要其中一份版本因功能或除錯 (features or bugs)問題經變更後,則位於其他電腦內的版本也必須保持其一致性。

這種頻繁且複雜的變動管理追蹤,幾乎是無法透過手動方式來管理的,自然而然,一個好的版本控制系統 (version control system, VCS),就要能擔負起下列的管理工作:

  • 對於所有團隊成員們的開發文檔 (尤其係指程式碼),要能保持一致性 (consistent)。
  • 因為錯誤的修改或遺失檔案,可以很輕易地回溯 (revert)至原來的狀態。
  • 任何再細小的變動,都可以知道是誰做了修改。
  • 可以輕易地部署 (deploy)不同版本的程式碼至開發或產品的伺服器內。
  • 團隊所有成員甚至可以利用 VCS 當成相互溝通的媒介。

儲庫 (Repository)

儲庫[1]是版本控制系統的核心組件 (core component)。它是一種資料倉儲的概念,主要儲存著下列的資訊:

  • 一組具階層性 (hirarchy)的檔案與資料夾結構。
  • 儲庫內的歷史性變更紀錄 (historical record of changes)。
  • 一組提交的資訊與指向該提交的指標,稱之為表頭 (head)。

簡而言之,版本控制系統的儲庫就是儲存著多個版本的文檔資訊。基於儲庫的位置所在,可以大致區分為兩種類型的版本控制架構。

集中式版本控制

集中式版本控制 (Centralized Version Control)是典型的「主從 (Client/Server)」 架構。記錄著多個版本檔案的儲庫是置於單一的伺服器內,並提供給具有存取權限的多個用戶端從伺服器提取檔案,所有的變更與提交等資訊均必須在連線到伺服端後才得以完成工作。

最普為人知且為免費開源的集中式版本控制系統,就屬 CVS、Subversion 為代表,並幾以成為業界所熟悉的版本控制標準模式了。

集中式版控系統模型

圖1-1:集中式版控系統模型

參考上圖1-1,集中式版控系統只有一個儲庫,是位於伺服器內。用戶端連線後發出 update 更新指令,就會從中央儲庫內複製一份工作複本 (working copy)至區域端電腦內;當開發者新增或變更檔案內容後,則需要提交 (commit)至伺服器的儲庫內;當儲庫與工作複本的檔案內容有不一致發生衝突 (conflicts)的現象時,則需要作合併 (merge)的動作。

閱讀全文 »

[筆記] 關於 Git Submodule 建立主從儲庫的關聯

問題:

我有一個利用 Sphinx 建置的文檔專案,並已上傳至 GitHub。該文檔專案的 theme 是自行設計,並準備給多個文檔專案引用 (也就是共用),所以 theme 也是視為另一個專案,並也上傳至 GitHub。

這樣的作法可以確保爾後所有的文檔專案,都可以引用到最新版本的 theme,而不用個別採複製、覆蓋的方式來個別維護 theme 的檔案結構。

所以該如何讓文檔專案可以引用 theme 專案,建立關聯?

解決方案

利用 Git submodule 指令,讓該文檔專案將 theme 專案視為主專案內的子模組。

簡單作法:

閱讀全文 »

初識 Git∣GitHub-Git 簡史

Git[1]是由 Linux 之父-托瓦茲 (Linus Torvalds)為了維護 Linux 核心 (kernel)所開發出的版本控管工具。

早於 1991-2002 年間,當時 Linux 系統的核心維護,僅以補丁與備份性檔案 (patches and archived files)的方式實現。而後當 Linux 核心的維護規模日益龐大後,核心團隊決定與當時一家提供商業性版本控制系統-BitKeeper 合作,由其免費提供核心源碼的儲庫 (repository)。

這段蜜月期至 2005 年時,Linux 核心開源社群與 BitKeeper 結束長達三年的合作關係,而這也使得核心團隊必須著手開發屬於他們自己的版本控制工具。從 BitKeeper 的使用經驗中,他們制定了新的版本控制系統需要能達成下列幾個目標:

  • 速度。
  • 簡單設計。
  • 可以給予數以千計並行分支 (parallel branches)的非線性開發模式強力支援。
  • 完全分散式。
  • 能有效處理如 Linux 核心大型專案的規模 (速度與資料量的考量)。
  • Git 自 2005 年誕生以來,日益成熟且易於使用,而且還能維持原來的初衷-確實履行上述的目標設定;而最為人樂道的分散式架構,已證明更能有效應用在大型的協同式專案開發。有別於 CVS/Subversion 的中央集權控管方式,Git 可以不需要伺服器就可以在單機上運作版本控制,這也使得原始碼更容易發佈與分享。

    閱讀全文 »

[摘要] 安裝與設定 Sphinx@windows 作業環境

※ 在 Windows-based 的作業系統要能具 Sphinx 的文檔寫作機制,務必要先安裝好 Python 的編譯環境。而且要對應 Sphinx 所對應的版本,例如 Sphinx 1.2b1 對應的是 Python 2.5 以上,那就不要安裝 3.x 或 低於 2.5 以下的版本,很可能 Sphinx 在編譯文檔時就會發生問題。

**2013/06/15 **
Sphinx 可以安裝在 Python 3.3.2 的環境下。先至 Python Package page for distribute 下載最新版 distribute 套件,解壓縮後至該目錄執行:

 C:>python distribute_setup.py

就可以利用 easy_install 安裝 sphinx 套件。

安裝 Sphinx @Windows 環境

參考官方安裝-Windows: Install Python and Sphinx;另一份-在 Windows 7 環境安裝 Python 2.6.6

  1. 安裝 Python : http://python.org/download/ (注意與 sphinx 搭配的 python 版本)
  2. 增加兩個 PATH 環境變數 (控制台 → 系統): C:\Python27;C:\Python27\Scripts
  3. 命列列模式下,安裝 setup tools (如此安裝 3rd party 套件會更容易):
    C:>python distribute_setup.py

    ※ 如無法自動下載 distribute 套件,則至 https://pypi.python.org/pypi/Sphinx 下載該檔並解壓縮後,至該目錄執行上述安裝指令。

  4. 利用 easy_install 安裝 Sphinx (在命令列模式下執行 easy_install.exe)。
    C:>easy_install -U sphinx

快速建立 Sphinx 預設文檔結構 (可視為每一份文檔的基礎框架)

官方主要參考文件:First Steps with Sphinx。

閱讀全文 »

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal