Joined Tarabut Gateway

A leading Open Finance company headquartered in Bahrain, with offices in UAE, UK and Saudi.

Agile Workflow: Split Known Bottlenecks into “Ready for” and “Doing” Columns

What:

Separate stages where work waits vs. actively progresses (e.g., "Ready for Development" and "Development").

Why:

Improves WIP limit management (e.g., limit "Development" to 3 tasks, but allow unlimited "Ready for Development").

Reveals wait-time bottlenecks in reports.

How to Implement:

Edit your workflow → Add statuses like:

• ✅ Ready for Review
• 🔄 In Review

Set WIP limits in Jira’s board settings.

Example Workflow:

Backlog → Ready for Dev → Development → Ready for QA → Testing → Done

Common Pitfall:

Avoid over-splitting (e.g., "Ready for Dev," "Almost Ready for Dev"). Stick to one "Ready" queue per stage.

Blocked status or Flag item

I have seen many teams introduce a "Blocked" status in their workflow, appearing as a column on the board to highlight something is blocked. I think there is a better alternative: Use the Jira Flag

What:

Highlight externally blocked items (e.g., waiting on a vendor) using Jira’s built-in flag.

Avoids creating a dedicated "Blocked" column in your workflow.

Why:

Preserves workflow clarity by showing where the blockage occurred (e.g., "Development" vs. "Testing").

Compatible with metrics tools like ActionableAgile.

How to Implement:

Right-click an issue → Select Flag (or use the Alt + S shortcut).

Add a comment explaining the external blocker.

Pro Tip:

No flag needed for internal blockers (e.g., team dependencies). These will naturally reflect in cycle time metrics.

Our new CEO has arrived

Michael Chan will be our new CEO after departure of Olivier Crespin

Using helm-secrets

Helm secrets is a great plugin to avoid checking in secrets in your Source code.

Here, I am using Hashicorp vault to store secrets and retrieve them safely in helm values files while installing helm charts.

Installation

$ helm plugin install https://github.com/jkroepke/helm-secrets

Setup

  $ export VAULT_TOKEN="s.VAULT_TOKENEXAMPLEASLDKASKDASDA" 
  $ export VAULT_ADDR="https://vault.example.com" 
  $ export HELM_SECRETS_DRIVER=vault

In vault, add the secrets:

In your helm values file, refer to the secret as follows:

db:
  db:
  database:     !vault secret/misp#db_database
  username:     !vault secret/misp#db_username
  pasword:      !vault secret/misp#db_password
  rootpasword:  !vault secret/misp#db_rootpasword

Now change the helm upgrade command as follows:

$ helm secrets upgrade misp ./helm/misp --install --wait --atomic  --namespace=misp --create-namespace  --values=./helm/misp/values.yaml

The secrets plugin will fetch and update the vault references in values file before invoking the upgrade command on helm.

Note:

To check the result of decoding, you can use:

$ helm secrets dec helm/misp/values.yaml

This will result in vaules.yaml.dec with actual decoded values from Hasicorp Vault.

GitHub action with matrix (parallel) jobs for each of the item in a JSON file

I have a file

deploy-list.json:

{
    "apiList": [
      "abc",
      "def"    
    ]
}

I would like to run a GitHub action with matrix (parallel) jobs for each of the item in the apiList above.

name: API Build

on: 
  workflow_dispatch:
    inputs:
      branch:
        description: 'Github Release Branch Name'
        required: true
        default: 'release/1.5.3'

  push:
    branches:
    - 'develop'

jobs:

  build-matrix:
    runs-on: ubuntu-latest

    steps:

      - name: Checkout Branch
        uses: actions/checkout@v2
        with:          
          ref: "${{ github.event.inputs.branch }}"

      - name: Set Matrix
        id: set-matrix
        run: echo "::set-output name=api_matrix::$(cat deploy-list.json | jq -c '.apiList')"

    outputs:
      api_matrix: ${{ steps.set-matrix.outputs.api_matrix }}

  build-api:
    environment: PRD
    needs: build-matrix
    runs-on: ubuntu-latest
    strategy:
      matrix:
        api_name: ${{ fromJson(needs.build-matrix.outputs.api_matrix) }}
    steps:
      - name: Checkout Branch
        uses: actions/checkout@v2
        with:
          ref: "${{ github.event.inputs.branch }}"

      - name: Building ${{ matrix.api_name }}
        run: |
          echo ${{ matrix.api_name }}
          # Do something here

Two parallel jobs will be invoked for "abc" and "def" apis making the workflow complete in twice as fast build time. I also using maven caching to speed up the builds even further.

Preventing secret leaks

I have added secrets to git repositories more than once in my lifetime.Once I even did it in a public repo.

One way to avoid this is to use a tool to detect secrets in the source code. This will come in the category of SAST tooling.

$ brew install gitleaks
$ brew install pre-commit
$ cd /path/to/repo
$ curl https://raw.githubusercontent.com/giantswarm/apiextensions/master/.gitleaks.toml -o .gitleaks.toml
$ git add .gitleaks.toml
$ git commit .gitleaks.toml -m "Adding .gitleaks.toml"

// Run scan
$ gitleaks detect --config=.gitleaks.toml

We don't repair anything...

We don't repair anything these days, not even relationships.

- S.A.