karatejb

Sunday, June 5, 2022

[Golang] gqlgen: Get started

Golang GraphQL gqlgen GORM

▌Introduction

[Architect] 產品及專案架構設計思維

最近常常被問到，如何為一個產品或專案設計好的架構？

我回答得很簡短：「首先要了解目的，然後因應當時的環境、時間和資源，評估可以達成這個目的的架構和流程，就是當時最適合的方式。」

然後就會得到

趁著最近比較有空，我把一些自己的想法整理在這篇文章。
但是在更往下之前，我想先談談自己對於 "架構" 這個詞的定義。

架構

我們知道產品和專案都有自己的生命周期。而我自己心目中的架構是支撐它們可以在各自生命週期運行良好的軟硬體、流程和方法。例如：

功能開發完成後，團隊可以多久和以多少信心佈署到正式環境？
新進員工加入多久，可以獨立開始作業？
線上有問題時，流程是什麼？
不同團隊協作流程順暢嗎？
軟硬體架構安全嗎？有考慮到業務成長量的對應擴充方式嗎？
開發團隊的價值有傳遞給客戶嗎？我知道客戶在抱怨還是幫我們說話嗎？

所以如果你期望看到底下有軟硬體架構的解決方案，很抱歉並沒有 XDD
這篇文章講得是我個人的思維。

目的

講到"目的"，通常我們想到的是：「如期如質上線，滿足老闆或客戶（或BU單位）的需求，讓公司營運正常並賺錢。」

這個大方向沒錯，但是我們再切成 "人"、"系統" 和 "業務" 來看的話，可能就沒有那麼單純。以系統來看我們要達成的目的，我們至少必須要知道

分辨必要（Must have）或是次要（Nice to have）的功能。
Sizing，未來幾年的業務及系統成長量。
SLA, SLO。
如果是專案，專案合約可能有明訂一些必要的規劃和使用的技術。

至於架構設計為何需要考慮到人（即利害關係人）？原因是每一項任務的成因和老闆的期望，可能不是我們想的那麼單純...

政治因素、外包廠商、專案價格... etc（還有不好說的那部分），都會影響到我們評估要花多少資源在整個架構及任務上。或許老闆的期望是讓團隊花更多時間在研發上，那我們就可以花更多資源在設計解決方案上。

業務角度也是重點，產品的業務是以套裝解決方案、或客製化收入為主？以 SaaS 還是導入客戶端來做為服務重點？上線後的維運單位和成本？這會影響到我們的架構設計和技術選型。

當時的環境、時間和資源

試著回想起三年前或最近剛上線的專案，是不是覺得有更多改善的空間？肯定是的。
但是當時的情況允許我們用目前更好的架構或方式來建置嗎？不一定。

考慮環境，包含法規、公司及部門政策和團隊素質。如果我們的解決方案和架構，和現行環境有衝突的話，就要回過頭去思考目的和思考必要的 tradeoff`。

至於時間和資源，就不用多說了，鐵定是要考量的因素。

我自己衡量的標準是

先理解相關利害關係人的期望，在可以完成任務及先滿足擁有權力和資源的關係人（通常是老闆和客戶）的情況下，去嘗試取得更多時間和資源完成團隊的期望。
透過數據、經驗和知識來下決策，有的時候我們必須要堅持對的事情，去和老闆或客戶持續溝通。
團隊素質如果高的話，可以在過程中去做更多嘗試和想法，這有利於在架構設計上有更多的選擇和彈性。

當然現實情況是殘忍的，經常不會有最佳的資源去達成我們想要的方式，仍是取捨問題。

當時最適合

當時最適合的決策和設計，現在回顧可能是錯誤的；也表示我們現在已經成長了也學習到更多經驗和知識，來理解如何用更好的方式來處理它。隨著資訊越來越進步、技術推陳出新，團隊掌握更多知識和經驗（不管從內部或外部），可以讓我們更快、更準確的於當下做更適合的決策。我自己的想法是，勇於改變和挑戰，即使結果不如預期，勝於什麼都不想改變。

Thursday, May 26, 2022

[Testing] Automation flow by Robot Framework, GitHub Actions and Postman Monitor

Robot Framework GitHub Actions Postman Monitor

▌Introduction

Due to COVID-19, many people work from home and need to clock in or out online on working days.

Since I sometimes forget to clock in or out online and I am so lazy to open the HR website and enter user ID/PWD each time on it, I decided to make the automation clock in(out) flow by E2E testing stack.

I use the stack as following:

ü Robot Framework

ü Azure Container Registry

ü GitHub Actions

ü Postman Monitor

▌Steps

▋Record and prepare the E2E automation test

I use Katalon Recorder and Robot Framework to have both automation test as clock_in.robot and clock_out.robot.

I would like to run the tests in Docker environment, so I made a dockefile and could be built and published the Docker Image to a private Docker registry (e.q. Azure Container Registry).

See my previous article, [Robot Framework] Run E2E test by Chrome and SeleniumLibrary in Docker, for the implementation details.

Now, I have to find a way to pull the Docker Image and then run the tests automatically.

▋GitHub Actions

GitHub Actions supports amazing and easy way to automate the workflow.

This article, [GitHub] Github Actions - Workflow dependencies, shows how to pull and run a Docker Image by GitHub Actions workflow.

Here is the YAML file of workflow that has workflow dispatch event. I will talk about why using workflow dispatch instead of schedule event later.

▋docker_clock_in.yml

---
name: Docker Clock In
on:
  # schedule:
  #   - cron: '10 0 * * 1-5'
  workflow_dispatch:
    inputs:
      trigger:
        description: "The trigger"
        required: false
        default: "Postman Monitor"
      trigger_datetime:
        description: "The datetime for triggering the workflow"
        required: true  
jobs:
  clock_out:
    name: Clock In
    runs-on: ubuntu-18.04
    steps:
      - name: Print Environment Variables
        shell: bash
        run: |
          echo "Arguments are ${{ github.event.inputs.trigger }}, ${{ github.event.inputs.trigger_datetime }}"
      - name: Docker Run
        uses: addnab/docker-run-action@v3
        with:
          username: ${{ secrets.ACR_USERNAME }}
          password: ${{ secrets.ACR_PASSWORD }}
          registry: ${{ secrets.ACR_REGISTRY }}
          image: ${{ secrets.ACR_REGISTRY }}/robot-bank:latest
          options: --rm --shm-size=2gb
          run: |
            robot /usr/src/rf/tests/ClockInOut/clock_in.robot

And my GitHub Actions secrets:

After pushing the workflow YAML file to main/master branch, I can trigger the workflow (open the headless Chrome, go to HR website and then clock in) in three ways.
(Reference: Manually running a workflow)

1. GitHub CLI: gh workflow run <workflow>

2. Run the workflow in GitHub Actions UI

3. Run the workflow by sending the HttpPost request to

https://api.github.com/repos/<user_id>/<reponsitory_name>/actions/workflows/<workflow>.yml/dispatches

Notice that we have to set a Personal access token for Authorization header.

(See GitHub Docs: Create a workflow dispatch event)

▋Why not use schedule event but workflow_dispatch?

I commented out the schedule event in docker_clock_in.yml, and use workflow_dispatch event instead. The reason is that schedule event has a uncertain delay time and won’t be trigger on the schedule time precisely. If your job can tolerates a delay time, schedule event might be a good way to trigger it. However, since I need to clock in before my office hours so I use Postman Monitor to automatically send the request for running the workflow.

▋Postman Monitor

Postman Monitor is the collection-based monitor that we can execute a collection of requests and collect the response time and result by scheduled time. Furthermore, it runs on Postman's cloud infrastructure, which is hosted by AWS. In other words, we do not need a live machine to execute the target request(s) by Monitor.

The following is my monitoring setup for requesting the clock-in workflow_dispatch API.

After dispatched the workflow, the workflow will pull and run the Docker Image that has automation tests for my clock-in or clock-out.