2018年1月19日 星期五

The DevOps Journey – Index

前幾年的DevOps大多談的是概念,但從去年(2017)中開始,大家慢慢發現DevOps中工具的使用或許也是導入成敗的關鍵之一。

許多人談DevOps導入時主要談的是文化,這沒錯,我自己也曾經在分享時提過,企業的文化決定了DevOps的推動是否順暢。然而,要怎麼改變文化呢?

文化的養成是透過日復一日的行為,從行為培養成習慣,從習慣慢慢造成影響(或制約),進而形成文化,而工具在這習慣養成過程當中,著實有不可或缺的一席之地。

我們使用VSTS/TFS已經有很多年,也在敏捷開發和Scrum上有過數年的實戰經驗,底下這些,是這些經驗的一些整理和分享,內容從觀念到工具,希望能提供給對敏捷開發或軟體生命週期管理有興趣的朋友。

我先定義一下我們的範圍:

  • 採用的開發技術包含.NET傳統桌面應用程式和網站、iOS和Android開發,使用的DevOps/ALM工具主要是VSTS/TFS(版控包含Git和TFVC),從需求、設計、開發、測試、CI、CD、線上監控、客戶反饋…大致上都有涉及。
  • 開發團隊包含設計人員(Designer)、前端開發人員、後端開發人員,當然還有PM(PO)、客戶服務(或Sales)

底下是系列文:

相關文章

希望這些經驗對大家有幫助。

-----------------------------
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM
相關電子書:https://www.pubu.com.tw/ebook/38227
若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

2018年1月11日 星期四

the DevOps journey (10) - 讓用戶輕鬆建立並管理Feedback/bug/Issue

Excel,是過去傳統軟體開發專案當中,管理Bugs/Issues常見而行之有年的工具。既然行之有年,表示有其存在的原因,然而,卻也帶來了不少問題。

Excel控管的Bugs/Issues,由於是檔案形式的存在,因此無法多人同時更新維護,即便現在可以透過雲端共用檔案來解決,但想要在Excel檔案上掌握bugs的狀態、控管處理進度實在很不容易,且一份Excel也無法完整描述出bugs/Issue的重現步驟(Step)、錯誤來源、以及用戶的電腦設備環境…等資訊。

既然,我們已經用VSTS來處理工項,一定會更希望這些bugs/issues的管理可以如同Backlogs一樣,輕鬆紀錄每一個狀態、讓各種問題有效的被追蹤處理。

上圖是VSTS中工作項目(Work Items)與Bugs的呈現畫面,過去開發人員或測試人員,可以在底下這個畫面中添加Bugs,便於管理:

但這樣,用戶得要先進入VSTS畫面,且填寫bugs時常常需要剪貼畫面,書寫comments,來來回回很是麻煩,有沒有更簡單的方式?

有的,Test & Feedback Tools,它在VSTS的Marketplace中,可以從這個網址進入,這絕對是一個優秀好物:

這是一個讓測試人員或stakeholder使用的工具,只要你為專案的測試人員或相關人員建立一個免費的stakeholder權限帳號,即可使用此工具,輕鬆截圖回報bugs。

測試人員點選上面install之後,會看到它目前支援Chrome/Firefox (對,尚未支援Edge和IE,why?不要問,何必問呢? ):

點選安裝之後,可以輕易地把這個外掛裝入Chrome瀏覽器:

安裝完成之後,你會發現瀏覽器多了這個圖示:

點選該圖示之後,會出現底下畫面,第一次使用時,請著點選齒輪:

點選齒輪之後,會看到底下畫面,請依序選擇Connected,填入你的VSTS/TFS網址,按下Next:

接著應該會出現一個登入畫面,如果有,請輸入你想要處理的專案的Microsoft Account(VSTS),驗證完身分之後,接著會出現底下畫面。

這個畫面中會出現你的帳號可以管理的專案,請選擇你的Project以及Team/Area,選定後按下Save:

這樣,Test與Feedback工具就與你的專案綁定了。接著可以怎麼用呢? 請看。

你可以先在網址列輸入你專案的測試網站(下圖以google為例),在進入你專案的測試網站之後,可點選該圖示叫出Feedback工具:

按下上圖中的『開始』鈕之後,可以開始一個新的session,你會發現目前進入到了錄製狀態,這時,你可以點選下圖的Capture按鈕,如果滑鼠點的右下角一點,還可以選擇要錄製的對象:

你可以擷取畫面也可以錄製連續動作:

甚至,還可以在擷取到的資料上面加上標記或註解:

你會發現可以繪圖,可以寫文字註解,完成之後按下上面的『V』,然後你會發現已經截取好了一個session:

這時請注意,千萬不要先按下『停止』鈕,不然剛才截取的資料就沒了,你可以先按下下圖這個Create bug鈕:

會出現底下這樣的視窗,讓你建立一個新的Bug單:

請輸入bug標題,勾選是否要加上logs…等資訊,完成之後按下Save。

你會發現,很神奇的,這個Feedback tool不僅幫你把bug存入了先前綁定的VSTS/TFS站台:

點開來之後,還會看到先前截取的內容,以及用戶的系統狀態:

這個Feedback工具相當便利,用戶無須複雜的安裝,只需要一個Chrome瀏覽器外掛套件即可完成Feedback/Bug的回報,也不需要會操作VSTS,即可把feedback直接送入VSTS當中,和VSTS的整合性之高,令人驚豔。

-----------------------------
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM
相關電子書:https://www.pubu.com.tw/ebook/38227
若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

2018年1月8日 星期一

使用C#開發LineBot(18) – 輕鬆偵錯你的WebHook

上週六在Study4.tw社群分享中,有位學員問到一個很常見的問題,Linebot的WebHook該如何Debug呢? 因為是跑在伺服器端,production的時候要偵錯非常困難。之前我們也說過可以寫Log和把Exception透過Line傳給Admin等方法,但畢竟沒有像是我們習慣的單步偵錯那麼直覺,我們是否有可能可以在production環境中單步偵錯嗎?

我得說,不適合,但技術上確實可以。

production是正式環境,在正常狀況下我們不可能去單步偵錯,但其實,在技術上,我們可以透過azure web app的遠端偵錯,來實現正式對外環境的單步偵錯,如果不放心,你也可以在production以外,建立第二個對外的staging測試環境,來實現單步偵錯。

接下來這篇,我們來看看如何使用這個功能。

如果你用Azure Web App作為你的WebHook hosting網站,並且使用VS2015以上的開發工具,那恭喜你,其實你是可以在PC上,透過IIS提供的遠端偵錯機制,來進行遠端伺服器端的單步偵錯,就好像在locahost上偵錯一般。

當然也沒有『完全』一樣,至少,會慢很多。畢竟,他是連結到遠端的網站,別太苛求。

如何實現呢?有幾個要素,分別是:

  1. 你的WebHook所在網站必須是Azure Web App(或IIS 7.5以上)
  2. 你deploy上去的必須是debug version(而非release version)
  3. 你的開發環境至少是VS2015。

怎麼使用呢?

首先,請先把你的WebHook透過Visual Studio佈署上azure web app(當然你要先申請好網站),請特別留意,你佈署的時候,底下這步驟時,必須選擇debug(而非一般的release):

完成後,請打開你Visual Studio的Server Explorer,在其中找到Azure item,展開『App Service』(如果你從未登入過,在進行這個步驟時,VS會要求你登入,請以你可以登入portal.azure.com建立該Web App的帳密登入),找到你的Web App所屬的Resource Group,然後將其展開,會看到該Resource Group底下所有的Azure Web App名稱,這時,請點選剛才以debug模式佈署的Azure Web App,按下滑鼠右鍵選擇『Attach Debuger』:

一陣運行之後(會需要一點時間,依照您的網路與PC速度而定,大約1-2分鐘)您會發現您的Visual Studio進入了偵錯模式,這時您所建立的中斷點就可以使用了。

神奇的是,在這個模式底下,您其實是偵錯『遠端』的Azure Web App網站,這時候遠端網站上任何的運行,將會觸發您本地端visual studio的中斷點,您可以看到遠端網站記憶體中的變數、可以單步執行,所有的運行就跟在本機localhost偵錯時完全一樣。

當然,唯一最大的差別就是速度,你會發現根本地端偵錯比起來,明顯的比較慢,同時您也要留意,不該用這樣的方式偵錯『正式機』上的Azure Web App,也不該把debug模式的code佈署到正式機。因為這會導致您的用戶在運行時發生意料之外的狀況或停頓,也有可能造成安全性上的疑慮。

因此,您應該在Azure上建立另外一個測試用對外部開放的Web App,部署測試用的WebHook,來進行這樣測試。

但好處是,這樣的偵錯對開發人員來說比較熟悉,也容易找到程式碼邏輯上的錯誤,比起透過try…catch或埋一些log的方式,要便利很多。

------------------
相關課程:http://www.studyhost.tw/NewCourses/LineBot
電子書:http://studyhost.blogspot.tw/2017/12/line-bot.html
LineBotSDK:https://www.nuget.org/packages/LineBotSDK
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2018年1月3日 星期三

[index] 使用C#開發LineBot 系列文索引

Line bot這一系列,從2016年五月開始,寫著寫著也快20篇了,差不多剛好一個月一篇,如果資訊雜誌還在的話,差不多可以是一個專欄。

很久沒有整理索引了,2018年初,將這一系列相關連結整理如後:

使用C#開發LineBot (1) - 用c#建立一個LineBot
使用C#開發LineBot(2) - 新版Line@ Messaging API使用心得 (Line Bot v2)
使用C#開發LineBot(3) - 使用LineBotSDK發送Line訊息
使用C#開發LineBot(4) - 透過asp.net輕鬆建立Line機器人WebHook
使用C#開發LineBot(5) - 透過程式碼讓Linebot發送圖片、貼圖
使用C#開發LineBot(6) - 不用申請Bot也能發訊息的Line Notify
使用C#開發LineBot(7) - 使用Line Login實現oAuth SSO(單一登入)
使用C#開發LineBot(8) - 發送Template Message
使用C#開發LineBot(9) - 取得新加入的好友身分資訊
使用C#開發LineBot(10) - 取得用戶上傳給Linebot的照片
使用C#開發LineBot(11) – Chat bot如何處理連續對話
使用C#開發LineBot(12) – 在連續對話中加入ButtonsTemplate訊息
使用C#開發LineBot(13) – 使用Date Time Picker讓用戶輸入日期資訊
使用C#開發LineBot(14) – 新版建立Line Bot流程(2017年底)
使用C#開發LineBot(15) – 當Linebot與我們同在一起, 談群組(聊天室)處理
使用C#開發LineBot(16) – 讓 WebHook 開發更輕鬆
使用C#開發LineBot(17) – 使用新版Line Login v2.1

------------------
相關課程:http://www.studyhost.tw/NewCourses/LineBot
更多內容,請參考電子書:http://studyhost.blogspot.tw/2017/12/line-bot.html
LineBotSDK:https://www.nuget.org/packages/LineBotSDK
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月30日 星期六

使用C#開發LineBot(17) – 使用新版Line Login v2.1

Line在去年以OAuth規格推出了Line Login機制,試圖與各家大廠一起角逐身分驗證與單一登入SSO(Single-Sign-On)的一席之地,相關的概念與使用方式我們在06年底曾經介紹過

而關於SSO與OAuth相關的技術與概念,我們也曾經在這邊有過分享。

今年(2017)底,Line又更新了Line Login相關的API,來到了v2以及v2.1,在這一版更新當中,Line Login可以跟Line bot做連結和整合,以便於讓你得知用戶更多的訊息並與用戶互動。除了功能比較多之外,還有一個你不得不升級的原因,因為舊版v1的API,依照公告,將於2018年三月底停用:

https://developers.line.me/en/news/2017/12/05/

因此我們的LineBotSDK也更著做了升級,我們後續將分幾篇貼文來介紹新版的Line Login API,這篇我們先來看基本SSO的部分,首先,由於申請畫面跟舊版有些許不同,我們也一併整理一下。

申請新版Line Login服務時,請先從 https://developers.line.me/en/ 的官方管理站台登入,登入後請點選主畫面的『Start Using Line Login』:

接著出現底下畫面,請依序輸入相關資料,其實本質上跟我們介紹v1時候的做法差不多,由於我們待會要做的是Web Site的SSO,下圖畫面請務必勾選Use Web:

輸入完成後按下 Confirm,最後會出現底下畫面,基本上一個服務就建立完成了。但相關資訊我們還要接著輸入,因此,待會請點選底下畫面中我們新建立好的這個Line Login服務圖示 :

進入後你會看到底下畫面:

其中大部分的資訊都是我們剛才自己輸入的,少部分是系統產生的,其中就包含了上圖畫面中標示A、B的部分,如果你熟悉OAuth flow就應該不陌生,上圖中的ID與secret就是我們要做SSO時的client_id與client_secret,不過新版Line Login底下多了一個Bot linked…的部分(標示C)我們後面再來談。

請留意畫面左上方有一個App Settings:

點選後會出現底下畫面:

我們待會按下上圖右方的筆,來修改這個callback URL。在此之前,我們當然得先產生出一個Callback URL才行。

如果你熟悉SSO與OAuth相關的技術與概念(不熟悉的話請先看這邊),你就會知道要與Line Login做整合,你的網站必須至少有兩個頁面,一個頁面是導入Line Login用戶登入的引導頁,另一個頁面則是Line Login將用戶導回我們網站時,接收Line伺服器所傳回的code的Callback頁面,上圖中所需要輸入的callback URL指的就是該頁面的位置。

因此,我們待會要透過Visual Studio以asp.net建立一個web site,其中包含兩個頁面index.html與callback.aspx,我們先透過VS建立一個空的網站,並且在網站中加上index.html以及callback.aspx這兩個頁面。

建立好之後,我們在index.html頁面中,撰寫如下的程式碼,這段程式碼的目的就是將用戶引導至Line Login的登入驗證畫面:

請留意6-12行,是組出引導入Line Login登入畫面的URL,其中與v1版本相比,比較不同的除了endpoint(7行)之外,最主要的是scope的支援範圍變廣了,寫法也不同,變成『openid profile』,這符合OAuth2的最新標準規範。

而其中第10行的localhost:58155我們之所以知道port no,當然是因為我們已經用VS透過IIS Express運行後的結果,這個callback.aspx頁面待會就是在用戶輸入完帳密,要被Line伺服器導回我們的網站時的code接收頁面,用來接收將會傳回來的code。

別忘了,我們也要同時把這個頁面的網址填入剛才在申請Line Login時的AppSettings項目下的Callback URL:

這樣Line伺服器才知道用戶輸入帳密驗證身分成功之後,要導回哪個頁面。

我們在該頁面中,也需要撰寫程式碼來接收將會從網址列傳回來的code參數。為了達成此目的,請將專案引入(或升級)至LineBotSDK 0.6.4-beta3 以上版本:

然後可以接著在callback.aspx頁面的Page_Load方法中,撰寫底下程式碼:

請留意我們用到的isRock.LineLoginV21.Utility.GetTokenFromCode()方法,必須在升級到LineBotSDK 0.6.4-beta3版本以上才有。

在上面的程式碼當中,我們首先在第4行抓取Line伺服器在callback回來時應當回帶入的URL QueryString參數code,如果該參數不存在,則顯示錯誤(7,8行)。

抓取到之後,我們可以透過GetTokenFromCode()方法取得token,注意第14,15,16三行分別要傳入你剛才在申請Line Login時候取得的Channel ID, Channel Secret,以及你自己設定的callback url,如果一切正確,運行後會得到一個回傳的token物件。

該物件中會有一個access_token屬性,透過該屬性,你可以輕鬆的以GetUserProfile()方法取得用戶身分資訊(第21行),我們在第22行將其顯示出來。

網站撰寫好之後,我們可以試著運行看看,首先運行index.html,按下底下的Button:

它會觸發我們在index.html頁面中所撰寫的javascript,將網頁引導至Line Login的登入頁面:

如果用戶不曾登入過,會出現上面這樣的頁面,讓用戶輸入他自己的Line帳號密碼,請留意該頁面並非我們做的網頁,而是Line自己做的登入頁,因此用戶的帳密我們無法得知,也能確保資訊安全。

倘若用戶曾經登入過,新版API會出現底下畫面,讓用戶選擇是否要切換身分:

用戶可以選擇上圖標示A的登入鈕,以該帳號直接登入(無須再次輸入帳密),或是點選上圖標示B的位置,以其他帳號登入。

用戶登入之後,將會看到底下這個畫面,圖中標示A、B的位置,顯示的是您剛才申請的Line Login服務的名稱、與說明:

而上圖標示C的部分很重要,這是舊版沒有的,也就是存取範圍(scope)的部分,由於先前我們指定的scopt為『profile openid』,因此會帶出上面標示C所顯示的這兩項『個人資料、用戶識別碼』,倘若用戶同意我們的網站可以存取該資訊,按下『同意』鈕之後,網站就會被Line伺服器導回我們撰寫好的callback.aspx頁面,並且跟著頁面傳來一個非常重要的code:

請留意導回的網址,你會發現網址列有傳給我們的code與state,跟Line Notify一樣,state是我們原先在index.html頁面中自行傳入的參數,它會被原封不動的回傳回來,便於我們做身分或交易識別用,而我們的主角是Line傳給我們的網址列參數code。

請參考我們剛才看到的callback.aspx中的程式碼,透過這個code,我們搭配client_id, client_secret與callback url作為參數,就可以用GetTokenFromCode()這個method取得我們想要的access_token(下圖標示A的位置):

取得access_token後,我們要抓取用戶身分也很容易了,可以參考上圖標示B的位置,我們傳入access_token,即可用GetUserProfile()方法來取得用戶的個人資料囉。

至此,我們的網站想要透過Line Login的方式,來進行SSO(Single-Sign-On,單一登入)也就不是什麼問題了。

後面我們再繼續談Line Login的相關功能與應用。

------------------
相關課程:http://www.studyhost.tw/NewCourses/LineBot
電子書:http://studyhost.blogspot.tw/2017/12/line-bot.html
LineBotSDK:https://www.nuget.org/packages/LineBotSDK
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月28日 星期四

真正的需求訪談,是談價值、而非只談功能。

前幾天聊到價值(Value),給我點時間,讓我細說從頭。

這幾年做案子下來,發現大多數的SA/PM/PO在需求訪談時跟客戶談功能很在行,談價值卻很吃力。你可能覺得疑惑,需求訪談不就是談需求嗎? 為何會扯到價值?

回答這問題前,先幫我想想,一個軟體的需求是為了什麼? 沒錯,需求是為了實現價值,功能則是需求的具體表現。

舉例來說,一個電子商務網站可以有各式各樣的功能,但核心價值要嘛是銷售、要嘛是服務,OK,這個你一定懂。

但大多數的SA或技術人員,受過了多年的技術訓練,談功能很拿手,各種工具、圖表、道具順手捻來毫不手軟,客戶看的眼花撩亂但也很開心,因為看到這麼多功能(工項)被列出來,腦袋裡自然而然幻想著,當這些功能實現,需求『自然』就滿足了,而需求被滿足,價值『自然』就實現了。

但真的是這樣嗎? 做那麼多年的軟體之後,你肯定知道,不是的。擁有一堆功能跟這個 軟體/網站 能不能滿足客戶需求乃至於實現某種價值,根本可以是兩回事。

然而很多客戶(和廠商)死不信邪,以為價值沒實現是因為功能不夠多(天殺的!!!這是我碰過最可怕的思維...)

然後試圖用無止盡的增加功能來滿足可能根本不存在的想像出的需求,然後在心裡期望價值能發生。(天佑PM/天佑SA/天佑客戶...)

每當我們要求跟客戶談需求時,試圖把焦點拉回價值(而不是一直停留在談功能上),一開始客戶都很不習慣,因為這仿佛很抽象,廠商自己也擔心,因為哪有一個網站可以保證上線後就財源滾滾而來? 就好比你賣一個ERP軟體要保障客戶使用後利潤增加一成,這...似乎有點難?

對,但就是因為這很難,所以久而久之,我們把價值放一邊,銷售時就拼命暗示客戶你有某種需求等著被滿足,而要滿足這些需求,則要做出這些功能,只要你買了這些功能,一切就搞定了。

然後,最初期待實現的價值呢? 恩...沒實現嗎? 不要緊,下一套軟體我們再來談...


------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
電子書:http://studyhost.blogspot.tw/2014/10/blog-post_1.html

如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2017年12月27日 星期三

MVP(最小可行性產品)的重點不是雛形、不是迭代、不是探索需求、而是實現價值!!!

最近網路上有幾篇文章,這篇文章中談到的MVP(最小可行性產品)那個圖,我在上課時也常用,也常被問到一樣的問題,而我的回答也總是很簡單...

在下圖中第一和第二個路線的例子裡,我們從來都不是說要做『一台汽車(太具體了)』,而是說要做一個運輸或交通工具(相對抽象),因為一開始你根本不會知道具體需求是甚麼,下圖中的『汽車』只是運輸器具的一種呈現方式,但根本不是一開始的目標...

(如果你做過產品,就會知道,開始時需求根本不可能是具體的,更不用說有什麼『清楚的規格』這種事情了,再清楚的規格,其實都是你自己的想像,只要碰到市場都會幻滅)

(講到這裡你應該知道我認為下圖是對是錯了,但重點在於,這些根本不是重點!!!)

這幾篇文章討論到最小可行性產品這個議題時,都少了一個我們做軟體專案時非常重要的概念,就是:『MVP的每個迭代(或交付)都必須要對用戶產生出價值(Value)』。

因此我在談MVP時的重點,從來都不是雛形(prototype)、也不是邊做邊改去符合(或探索)用戶需求,甚至不是其實我認為也很重要的快速反饋,而是『時刻產生價值』。

沒有帶來價值的產出,不管是滑板、腳踏車還是機車、汽車,對我(客戶)來說,都叫做『浪費』。

當客戶的預算有限、需求常常變、一切彷彿都捉摸不定時,你很有可能永遠都不知道客戶(或市場)到底最終要的是戰車還是超跑,但,不管你產出的是什麼,只要能在當下立即為客戶帶來『價值』,那就是好東西,否則不管你做出什麼曠世巨作或太空梭,只要沒能帶給客戶價值,我們都稱之為『浪費』。

敏捷專案管理中所追求的,是每一個迭代、每一次交付都要能為客戶帶來『價值(Value)』。這很不容易,但這才是我在乎的重點...

後記:關於價值,為何我們那麼看重? 後續我又做了一些補充,請參考這裡

------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
電子書:http://studyhost.blogspot.tw/2014/10/blog-post_1.html
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。