iT邦幫忙

teamcity相關文章
共有 41 則文章
鐵人賽 DevOps

技術 終章:TeamCity 進階學習路徑

之前有幸在一次機會裡,與幾位在 DevOps 領域深耕多時的前輩對談。那時前輩曾提到,在帶新人時都會要求他們先「手動」的把整個工作流程的每個環節都做過一次,然後...

鐵人賽 DevOps DAY 30

技術 第三十天:為 TeamCity 設計的 Kotlin DSL

一直以來,我們使用 TeamCity 時都是透過 Web UI 來設定,不論 Project 的 VCS、Build Configuration 都是。雖然 W...

鐵人賽 DevOps DAY 29

技術 第二十九天:為 IntelliJ Platform 設計的 TeamCity Plugin

在我們整個系列教學裡,所有的操作都是在 TeamCity 的 Web UI 上完成,而 TeamCity 的 Web UI 的確設計的很好用也很漂亮,在上面完成...

鐵人賽 DevOps DAY 28

技術 第二十八天:用 TeamCity 發佈 Package

在這系列教學裡,我們以撰寫一個以購物車為主題的 Kotlin 函式庫為例,經過一連串 TDD、語法風格查、靜態分析、Build Scan、覆蓋率報告、API 文...

鐵人賽 DevOps DAY 27

技術 第二十七天:用 TeamCity 部署 API 文件

在昨天的練習裡,我們使用 TeamCity 在建置流程的最後一步產生 API 文件,並讓文件可以直接顯示在該 Build 的頁籤裡,方便我們直接瀏覽。不過顯示在...

鐵人賽 DevOps DAY 26

技術 第二十六天:在 TeamCity 上顯示 API 文件

昨天我們介紹了如何用 KDoc 語法標記程式碼並用 Dokka 來產生 API 文件,今天我們要將產生 API 文件這個動作整合進 CI 流程裡,讓 TeamC...

鐵人賽 DevOps DAY 25

技術 第二十五天:用 dokka 產生 API 文件

當我們在寫函式庫或框架的時候,通常表示這段邏輯很常用到,希望藉由抽取成函式庫或框架來重複使用,減少重造輪子、也更好維護。而身為函式庫或框架的作者,當然會希望有愈...

鐵人賽 DevOps DAY 24

技術 第二十四天:使用 TeamCity 監看覆蓋率變化

昨天我們在 Build Step 裡開啟 Coverage 的功能,讓 TeamCity 在運行測試後一併產生覆蓋率報告,方便我們了解程式碼庫的狀態及趨勢。不過...

鐵人賽 DevOps DAY 23

技術 第二十三天:在 TeamCity 上產生覆蓋率報告

昨天介紹了測試覆蓋率的概念,也在 IntelliJ IDEA 裡將 ShoppingCart 類別的測試覆蓋率實際算出來給讀者們看。不過實際在團隊合作上,覆蓋率...

鐵人賽 DevOps DAY 22

技術 第二十二天:為測試產生覆蓋率報告

每當我們為專案寫測試的時候,其實就是拿另一個程式來執行我們寫的程式,看看是不是能將程式碼裡所有可能的路徑都「走」過一遍,確保不會有意料外的錯誤發生。而這個所有路...

鐵人賽 DevOps DAY 21

技術 第二十一天:TeamCity 技術名詞回顧

經過 20 天的練習,我們已經大致掌握了 TeamCity 的基本功能,剛好是一個很好的機會來回顧一下這一段時間我們學習到的觀念、流程、動作以及接觸到的技術名詞...

鐵人賽 DevOps DAY 20

技術 第二十天:在 TeamCity 上執行 Build Scan

昨天介紹了 Gradle 的 Build Scan 功能,讓我們可以清楚的了解 Build 過程中的細節,是使用 Gradle 時的一個強大工具。當然,我們也可...

鐵人賽 DevOps DAY 19

技術 第十九天:用 Gradle 做 Build Scan

對 Kotlin 這種編譯式語言來說,為了方便每次更新後的編譯工作,都會搭配 Gradle 這種自動建置工具使用。而 Gradle 在編譯的過程中會經過很多手續...

鐵人賽 DevOps DAY 18

技術 第十八天:用 Plugin 擴充 TeamCity

昨天提到 TeamCity 支援幾個不同的通知頻道,可以在建置任務成功或失敗的時候通知我們。不過現在的通訊平台愈來愈多,每個團隊的偏好也不一樣,TeamCity...

鐵人賽 DevOps DAY 17

技術 第十七天:TeamCity 通知機制

自從有了 TeamCity 後,很多原本需要人工操作的任務都可以交給 CI 主機做。因為它會在每一次發現變更的時候自動執行,一方面不會漏掉或忘了執行、另一方面在...

鐵人賽 DevOps DAY 16

技術 第十六天:在 TeamCity 上執行靜態分析

昨天我們在專案裡導入了 detekt 靜態分析套件,只要執行 $ gradle detekt 就可以掃描整個程式碼庫,及早找出淺在問題。我們也介紹了如何在 In...

鐵人賽 DevOps DAY 15

技術 第十五天:用 detekt 做靜態分析

在現代開發工具的輔助下,大多數的編輯器或 IDE 都已經程式碼自動完成的功能,寫程式已經變得相對輕鬆些。不過我們還是得注意一個事實,就是程式寫完跟寫好還是有一段...

鐵人賽 DevOps DAY 14

技術 第十四天:在 TeamCity 上執行程式碼風格檢查

昨天我們在專案裡導入了 ktlint 這個用來檢查程式碼排版風格的套件,我們可以透過 Gradle 的兩個指令 lintKotlin 及 formatKotli...

鐵人賽 DevOps DAY 13

技術 第十三天:用 ktlint 做程式碼風格檢查

當我們自己一個人寫程式的時候,只要程式碼沒有寫錯,排版風格愛怎麼寫就怎麼寫,什麼時候要換行、什麼時候要空行都可自己決定。但團隊合作時就不一樣了,假如每個成員寫程...

鐵人賽 DevOps DAY 12

技術 第十二天:在 TeamCity 上執行測試

在昨天的練習裡,我們在自己的本機上完成了一個 ShoppingCart 的類別。因為是用 TDD 的開發流程,所以測試也一併寫好了。不過,雖然我們在自己的電腦上...

鐵人賽 DevOps DAY 11

技術 第十一天:用 TDD 實作購物車類別

有了前面的基礎,今天我們要在專案裡實作一個「購物車(ShoppingCart)」類別。為了確認實作符合預期的規格,我們將會以 TDD(Test-Driven D...

鐵人賽 DevOps DAY 10

技術 第十天:在 TeamCity 上完成第一個建置工作

在前一天的練習裡,我們雖然只寫了一個非常簡單的 Hello World 程式,但只要能在 Run 面板裡看到 Hello, world 字串的輸出,就表示我們已...

鐵人賽 DevOps DAY 9

技術 第九天:建立練習專案

接下來我們建立後續章節要使用的練習專案,我預想了一個「購物車及運費計算機」做為情境,整個流程會示範如何用 IntelliJ IDEA 寫程式並用 TeamCit...

鐵人賽 DevOps DAY 8

技術 第八天:安裝 IntelliJ IDEA

為了在後續章節裡示範 TeamCity 可以怎麼協助我們建置專案及一系列的自動化,我們需要有一個可以建置、可以跑測試、可以產生覆蓋率報告、可以產生 API 文件...

鐵人賽 DevOps DAY 7

技術 第七天:加裝 Build Agent

簡單來說,TeamCity 的運作方式是 Server + Agent 的架構。平常我們看到的 TeamCity 操作畫面是 Server 端,它負責提供 UI...

鐵人賽 DevOps DAY 6

技術 第六天:首次啟動設定

若是您選擇以軟體包或 Docker 這種 On Premises 的安裝方式安裝在本機電腦的話,那首次啟動時還有一些設定工作要做,今天就來看一下這些首次啟動設定...

鐵人賽 DevOps DAY 5

技術 第五天:使用 TeamCity Cloud

前面兩天我們討論了兩種安裝 TeamCity 的方式,雖然步驟不難,但假如要正式對外上線的話,還有一些額外的安全性防護要做,比方說主機的防火牆設定、為了走 HT...

鐵人賽 DevOps DAY 4

技術 第四天:以 Docker 運行 TeamCity

雖然 TeamCity 軟體包已經將所有元件都打包成 Jar 檔,還寫了可以跨平台使用的 Launcher,但對於只是想用 TeamCity 卻不熟悉 JVM...

鐵人賽 DevOps DAY 3

技術 第三天:以軟體包安裝 TeamCity

在對 CI/CD 有基本瞭解後,接下來就要把我們的主角 TeamCity 安裝起來。TeamCity 提供 3 種安裝方式,在接下的幾天會逐一介紹,讀者可以依據...

鐵人賽 DevOps DAY 2

技術 第二天:什麼是 CI/CD?

雖然一講到敏捷開發、DevOps 時就很常聽到 CI/CD 這些詞彙,不過到底什麼是 CI?又什麼是 CD?當我們導入 CI/CD 後,又會有什麼樣的好處呢?就...