【案例分享】金士頓推動 IT 開發團隊的數位轉型 – 結合 Visual Studio 與 Azure 發展行動化應用!

結合微軟雲端平台及開發環境,敏捷發展行動化應用!   從 Scrum 敏捷開發到 DevOps,從舊有企業應用走向行動化、雲端化,金士頓科技總是以最領先的腳步來保持企業系統的創新與競爭力,而且一以貫之地採用微軟的解決方案如 Visual Studio 與 Azure,來確保 IT 開發團隊的效率和方法論的實踐。   身為高科技製造業的金士頓,在推動 IT 開發團隊進行數位轉型的過程裡,成功結合了雲的力量、敏捷的開發方法、行動化的服務及應用。以在持續變化的市場裡,運用彈性快速的開發模式來因應需求的改變。

0

DevOps 影音特餐 – 團隊開發 Speed UP!(收錄 25 項免費資源)

MSDN 小編特別整理關於 DevOps 相關的文章與影片,總共收錄超過 25 種免費學習資源供大家使用!         DevOps 是目前火紅的話題之一。這個字是由 " Development " 與 " Operations " 合併而成。目的是要透過強調溝通 ( Communication ) 、合作 ( Collaboration ) 、整合 ( Integration ) 及自動化 ( Automation ) 等方式加強開發人員與運維人員還有其他包括質量控制等人員之間的合作。

0

行動應用開發平台寶典 (三) 行動 DevOps

前言 微軟的 Visual Studio Team Services、Team Foundation Server、Xamarin Test Cloud 與 HockeyApp 提供開發者與 IT 人員一個全方位的環境,讓您的團隊可以管理專案並快速地建置、測試與佈署行動 app 和後端的服務。

0

【案例分享】Olo 如何以行動 DevOps 來增強超過 150 家餐廳的訂餐 App

Olo 提供給顧客與員工使用的 Xamarin app 幫助餐廳的品牌傳遞更快更精確與更個人化的服務給它們的顧客,建立顧客忠誠度與改善餐廳的營運。擁有超過 150 個品牌與 25 萬用戶的業務量,行動 DevOps 對於 Olo 的行動策略至關重要,而 Xamarin 幫助團隊傳遞最高品質的體驗給他們全球的客戶。 今天我們邀請了 Greg Shackles,為 Olo 的首席工程師與長久以來 Xamarin 社群的成員,來分享他對於行動開發的經驗和他給立志作為 app 開發者的建議。  

0

【嚴選 TechDays 2015】十大熱門開發影片

雖然今年 TechDays 暫停一次,但緊接而來的是台灣為首場舉行的 Tech Summit Roadshow , 同樣綜合 Ignite + Build 的精華消息,還請大家拭目以待,現在讓我們一同回顧去年的 TechDays 的經典課程吧! 小編精選十大最佳開發課程,你心中的最佳影片得主是哪一部呢?或者是你認為哪一部影片是遺珠?歡迎留言與我們一同交流!

0

「突破隔閡的高牆」了解DevOps 的基本概念

在傳統的開發週期,開發團隊會將軟體版本丟過這道牆給營運團隊,營運團隊撿起這些版本構件並開始準備他們的部署,手動處理開發者提供或是他們自己建立的部署指令碼。他們也編輯配置檔案來反映生產環境,而這與開發或 QA 環境有極大的不同。最好的情況是他們正在複製之前環境中已經做好的工作,最壞的情況是他們即將引進或發現新的錯誤。

0

使用 App Service 進行多個 URL 的效能測試

自從宣布了網頁與行動應用程式的效能測試公開預覽版以及透過 App Service 持續部署進行效能測試的功能,最備受期待的功能就是複數 URL 測試。 我們持續地與 Visual Studio 負載測試團隊合作,並很高興地宣布這個功能現在已經上市了。

0

使用 Visual Studio Team Services (VSTS) 自動建置簽入 GitHub 的 Android 專案

Visual Studio Team Services (VSTS。原名:Visual Studio Online)是提供給開發人員或團隊協助開發工作的線上服務,它提供了像是專案管理、版本控制、自動建置、自動測試、部署發行管理等功能,並且支援各種程式語言、開發平台或是 IDE 工具等,如果是五人以下的團隊可以免費開始使用。(詳細功能與價格可參考這頁說明) 目標 這篇文章要完成的任務,是以 Android 專案為例子,並且使用 GitHub 為版本控制的工具(當然也可以用 VSTS 作版本控制,也支援 Git),而主角 VSTS 則是用來根據設定來自動執行建置專案的工作,自動產生建置好的 apk 檔案以便後續的發行部署。 操作步驟 Android 專案 本文中的例子,是以 Android Studio 所產生的專案結構為例子,這裡不必做任何特殊的設定或修改,就像一般一樣使用它來建立專案即可,而 VSTS 內建的 Android 建置範本是使用 gradle 腳本,所以如果關於建置工作的設定,可以修改 build.gradle 檔案的內容即可。 目前在 VSTS 上的 Android 建置環境,JDK 的部份支援到 8,而 Android 建置工具支援到 API Level 22,並且還不支援 Android Support Repository 以及 Android Support Library,如果需要這些函式庫,可參考另一篇…

0

【敬邀參加】2015 Microsoft DevOps Day 團隊開發日

2015 Microsoft DevOps Day 團隊開發日 立即報名 << 12/5 (六) 或 12/7 (一) >> 同一主題兩個場次,任君挑選!         您的團隊能很快地因應市場及使用者需求的改變加速改版嗎?您對目前團隊開發效率滿意嗎?無論您是來自大型企業、新創公司或獨立軟體開發商的研發團隊,無論您是團隊領導者或開發人員,都應了解如何建立出好的團隊開發及系統維運標準,積極擁抱改變,是追求團隊卓越的第一步! 在這個求新、求快、求變的世代,您千萬不能錯過 2015 Microsoft DevOps Day 團隊開發日,我們將為您呈現: 海峽兩岸實務案例研究:從中國互聯網浪潮下的企業 DevOps 轉型成功模式,探討台灣企業研發實力升級應具備之 DevOps 戰略與戰術! 從專案思維轉變成產品思維:從組織設計、開發流程兩方面,探討如何依托工具平台快速完成轉型! 微軟 DevOps 轉型的實戰經驗:作為全球最佳實踐之一,分享微軟 DevOps 轉型的獨家 Know-How! 運用雲的力量加速開發:精采的 Demo 讓您更深入了解如何駕馭雲的力量實現開發維運一體化! 來自微軟全球 Visual Studio Connect(); 開發者大會所宣布的第一手技術消息與改變!                    時    間    …

0

微軟開發部門 DevOps 經驗談 (四) – 從使用者經驗中學習

本文接續: 微軟開發部⾨ DevOps 經驗談 (一) – 從 Agile 邁向 DevOps 微軟開發部門 DevOps 經驗談 (二) – 從經驗中學習 微軟開發部門 DevOps 經驗談 (三) – 為 DevOps 量身打造的系統 今天要來談的是如何從使用者經驗中學習。 從使用者經驗中學習 我們盡可能讓所有開發的功能,都能提供良好的使用者體驗,就算這是件相當困難的事。舉例來說,我們花了很多功夫讓服務達到 99.9% 的服務可靠度 (SLA, Service-level agreement),但我們並不因此而滿足。 我們的目標並不僅僅只是 SLA,而是希望提供 100% 完全沒有缺點的服務。這也代表著我們必須要對發生機率是 0.001% 的例外狀況斤斤計較。由於異常狀況經常會隱藏在監控的數據之中,我們甚至為此改寫了三次計算 SLA 的演算法,來讓我們的監控標準更加的嚴謹。參考下圖一,在一開始,我們使用外部進入測試,來判斷服務是否正常運行,如圖表中的虛線所示,我們的第二個演算法是觀察所有使用者進行的操作指令中,失敗和執行緩慢的數量比例,來判斷是否有功能發生異常,你可以參考圖表中的失敗和緩慢指令數量。在服務成長之後,由於使用者數量過多,也可能會讓問題被隱藏在相對大的系統數字之中,目前我們的作法是計算每分鐘遇到問題的使用者數量相對於每分鐘所有使用者數量,作為判斷系統是否有異常的指標,如圖中黑色現所示。 圖一、呈現了計算SLA的三種演算法,外部進入測試沒有找到任何的異常,追蹤指令執行狀況呈現了有一小時發生執行緩慢的狀況,而在使用者異常相對比例中更反映了有三小時的執行緩慢情形發生。 如同你所看見的,在四個小時的週期中,第一條虛線顯示沒有異常,第二條線顯示大約有一小時的異常,而第三條線卻顯示了有三個小時服務的效能是十分糟糕的。其實我們沒有必要這麼嚴格的設定線上數據觀察的機制,但我們為了提供給使用者更好的服務品質,對每一個數據都會更嚴格的要求自己。 注重安全性 在我們服務的其中一個安全標準中,要求了我們必須確保服務能夠保護使用者隱私,確保資料安全,在提供穩定服務的同時維持安全品質。以前我們開發地端版本的軟體提供給客戶使用時,就曾經在軟體的安全性上下了不少苦工,甚至會假設如果服務被入侵時,要怎麼自動偵測或判斷服務的安全受到了威脅。 除此之外,我們使用擴展單元來部署服務的方式帶來了一些額外好處,SU0 除了作為我們服務的第一個部署單元之外,還可以透過它來進行安全演習,強化驗證並我們服務的安全性。我們會使用這個擴展單元來舉辦一些類似“遊戲日”的活動,例如在內部舉辦安全性比賽,看看服務是否能夠抵禦入侵,而使用 SU0 更大的好處是不會影響正在使用我們服務的使用者們! 不同的部署方式 在我們開發地端版本提供給客戶使用的軟體時,我們花了十分多的精力調整開發系統和流程,想辦法讓客戶使用軟體遇到異常的時間降低,換句話說,由於產品提供給客戶之後,萬一客戶在使用時發生任何的異常或問題,要處理的成本都會變得十分的高,所以我們必須要在提供給客戶前就盡可能的降低問題發生的機率,避免我們常常要發行修正更新給客戶來解決異常,也避免造成客戶對我們的軟體有不好的印象。 DevOps 以及服務的雲端化改變了我們的思維,我們要考慮如何盡可能降低修復問題和重新部署到線上服務的時間,這也讓我們有了不一樣的目標,同時必須還要考慮修復問題、發現問題、找到原因以及學習改善根本原因的時間。 我們還想到在設計時必須多為了彈性做考量。線上服務可能會因為周邊相關的系統中斷而導致異常,尤其是在使用量尖峰時段很容易發生,但既然是線上服務,就必須將使用上的影響降到最低,並搭配對應的重試機制,例如使用 Circuit Breaker…

0