Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
What Is GitHub Actions? Your First CI with Workflows, Events, Jobs, Steps and Runners
GitHub Actions is a CI/CD platform that runs the YAML workflows under .github/workflows on runners in response to repository events. We write a first workflow that restores, builds and unit-tests the Bookstore API, try it locally with act and actionlint, and cover uses versus run, the run log, re-runs and the reasoning behind the Web API 31 workflow.
Measuring and Speeding Up a Pipeline: DORA Metrics, Caching and Parallelism
DORA's current five metrics (change lead time, deployment frequency, failed deployment recovery time, change fail rate, deployment rework rate) are calculated from deploy records and should be tracked as team-level trends; speeding up a pipeline starts with measuring. A single-file C# calculator, a real act measurement where a NuGet cache saved only 0.2 seconds of restore at a 2.3-second restore cost, cache key design, and the path filter trap.
Pipeline Security and Secrets: Least Privilege, Short-Lived Credentials and Supply Chain
The pipeline is the most powerful user, holding production keys; keeping secrets in a store, least privilege per job, short-lived tokens via OIDC instead of long-lived cloud keys and pinning actions to commit SHAs close most of the risk. Real act output showing a base64-encoded secret escaping masking, script injection caught by actionlint, fork PR risks, and a short look at SLSA v1.2 and SBOMs.
Approvals, Gates and Deployment Controls: Adding People and Rules to a Pipeline
Automated gates (smoke tests, health checks, deploy freezes) should answer 'does this change work?', while a manual approval should answer 'now?'; DORA found no evidence that heavyweight external approvals lower the change fail rate. Real output showing that a Jenkins input step's submitter does nothing when everyone is an administrator, GitHub environment protection rules and Azure DevOps checks.
Environments and Promotion: Dev, Test, Staging, Production and Configuration
The same artifact moves through dev, test, staging and production without being rebuilt; the only thing that should change from step to step is configuration coming from the environment. Layered configuration in ASP.NET Core with appsettings.{Environment}.json and environment variables, a missing setting that fails at startup with ValidateOnStart, a difference inventory between staging and production, preview environments per PR, and masking non-prod data.
Testing in the Pipeline: Fast Feedback, Quality Gates and Flaky Tests
Ordering tests in the pipeline from cheap to expensive (formatting, unit, integration with Testcontainers, e2e with Playwright) and adding quality gates such as warnings, coverage and bundle budgets gives fast, trustworthy feedback; a flaky test needs its root cause fixed rather than a retry. How a test without assertions inflates coverage, a real flaky test failing 2 of 30 runs, and an empty Playwright shard.
Build Once, Deploy Many: Artifacts, Versioning and Immutable Packages
Building an artifact once and carrying that same artifact, by tag or digest, from staging to production guarantees that what was tested on staging is what reaches production; even building the same commit twice yields different images. Reproducible builds with lock files and npm ci, stamping versions with the commit SHA, the :latest trap, and a runtime config.json for Angular.
Pipeline Anatomy: Triggers, Stages, Jobs, Steps and Failing Fast
A pipeline starts with triggers and is made of dependent jobs (stages in Jenkins) and steps that run in order; putting the build logic in a script that runs locally, letting the pipeline only orchestrate, moving cheap checks first and failing fast across parallel branches all speed up feedback. A GitHub Actions, Jenkins and Azure DevOps term mapping, with real output from act and Jenkins.
CI, Continuous Delivery and Continuous Deployment: The Differences and Why They Matter
CI means everyone integrates into the mainline every day and every push runs an automated build and tests; continuous delivery keeps every commit releasable and leaves going to production as a decision, while continuous deployment removes that button too. An integration hell scenario, Fowler's 2024 practices, a CI workflow run with act, and the MinimumCD checklist.
Preparing for Git 3.0: What Changes, What Goes, What to Do Today
We separate the official status of Git 3.0 (BreakingChanges.adoc: no date yet) from the plan reported by GitLab and LWN. We try the main, SHA-256 and reftable defaults, safe.bareRepository, mandatory Rust, the commands being removed and why git checkout stays on Git 2.54, and end with a preparation checklist.
Git 2.50–2.56: git history, Config-Based Hooks and git add --resolved
We go from Git 2.50 to the current 2.56: git history reword and split (fixup in 2.55, drop in 2.56), config-based and parallel hooks, stash export/import, pull.autostash and what happens on a conflict, git last-modified, git repo info, reflog drop, branch --delete-merged, add --resolved and the -h exit code change.
Git 2.40–2.49: reftable, SHA-256, git replay and the New git config
We look at the 2.40–2.49 period, when the foundations of Git 3.0 were laid, with real output: the reftable ref store and git refs migrate, where SHA-256 repos stand today, git config's get/set/unset/list subcommands, worktree add --orphan, git replay, safe.directory prefixes, git backfill and Rust's first step.