Get Appointment

contact@wellinor.com
+(123)-456-7890

Blog & Insights

Basic setup

# To initialize
git bisect start

# Declaring the current commit as broken; a tag or commit hash can also be included if an earlier broken commit is already known
git bisect bad

# Declaring a specific tag as a working commit; specific commit hashes may again be used
git bisect good v1.2.0-release

At this point, Git will check out the commit at the midway point between the latest known working and earlier known not-working commits. From here, it is a simple matter to test the checked out commit and:

# If the checkout has the bug:
git bisect bad

# Or if it does not:
git bisect good

# Or, if there is something preventing testing with this specific commit:
git bisect skip

Every time a commit is determined to be good or bad, Git will automatically checkout the next "middle" commit to continue the process. In doing this, one can track down the commit that introduced the bug in O(log₂(n)) steps, in addition to any skips done in the process. That means even with a thousand commits, it won't take more than 10 steps to reach an answer. Ten thousand commits? Not more than 14 steps.

Workflow Considerations

The bisect feature is at its best when commits are atomic; that is to say small and focused changes that affect one logical area at a time. One bug fix, or one feature, or one refactorization are all considered atomic. Bisect results are most useful when they land on a small commit, as a small diff will make it clearer as to why an undesirable change has happened. Squash commits should also be avoided for this reason, as they remove history and make multiple smaller commits into singular large ones. It’s also a good idea to not commit work-in-progress commits, or commits that don't pass needed tests. This is not always possible to avoid depending on the environment. If this is the case, it would be wise to start commit messages by saying so, e.g. with "[WIP]" or something equivalent, to indicate that the skip command should be used immediately.

Automation

Good practices with workflow can also allow for ease of automation. Having a test suite that can determine if a commit is good or not can assist greatly. This can be done via exit codes:

0 for a successful run (indicating good)
A value between 1 and 124 or 126 or 127 for a failed test (indicating bad)
A value of 125 if a build failed (indicating skip)
Any other value to abort the bisect process

This test need not be a part of the repo itself, so any new testing that needs to be done won't need to interfere with multiple checkouts. To start automated tests, we begin in much the same way:

git bisect start
git bisect bad
git bisect good v1.2.0-release

# To declare how to test automatically:
git bisect run ~/tests/run-test.sh # or wherever your script is

Tests can be done inline as well. This is useful for many functions, with perhaps the best example being scanning output for a specific message or message fragment:

git bisect run bash -c '/usr/bin/env python3 main.py arg1 arg2 | grep -q "ERROR"'

Finally, using worktree, a specific current and committed test suite can also be defined, allowing checkouts of running code while leaving the most current tests intact:

git worktree add ../bisect-tests HEAD
git bisect run ../bisect-tests/tests/run.sh

Other uses

Finding the point of origin of bugs isn't the end of utility for Git bisect. Using other available scripts, one can use bisect to find performance issues. Some additional things that can be done include:

Finding when a performance issue began
Finding when a function or feature was added to the repo (with run grep -q)
Finding when CI pipelines began failing
Finding when a security vulnerably was introduced
Detecting when code coverage degraded

Bisect works well as a general purpose tool for determining when and where a change happened. The only requirement is that it is something testable with a script that can return a pass/fail response. Official Documentation: https://git-scm.com/docs/git-bisect. [table id=11 /] [post_title] => Gitting Good - Using Bisect - Git's Built-in Debugging Tool [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => gitting-good-using-bisect-gits-built-in-debugging-tool [to_ping] => [pinged] => [post_modified] => 2026-08-13 14:06:04 [post_modified_gmt] => 2026-08-13 14:06:04 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5281 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [1] => WP_Post Object ( [ID] => 5268 [post_author] => 7 [post_date] => 2026-06-30 14:09:24 [post_date_gmt] => 2026-06-30 14:09:24 [post_content] => Perhaps you are testing across multiple machines and don't want to push incomplete code. Maybe you are working with a colleague on a particularly long flight. Or perhaps your main repository has become unreachable, and you don't know when it will be back. Thankfully, Git has solutions for these times, without needing additional software or configuration to work with. At its core, Git is designed to not require a central service or authority to work. This might come as something of a surprise, since most projects use a central authority such as GitHub, GitLab or BitBucket. However, within your pulled repository exists a complete history of your pulled branch's changes, from the very first commit. Because of this, any machine can act as a Git server. This can be leveraged even with the general internet unavailable; no special services or daemons are required. Not even a reliable network connection is required, so long as you have a USB drive handy. All that you need between two computers is both having Git, and both able to communicate in some way.

Option 1 - Bare repo on shared media

Those of us who collaborated with others in a pre-internet world know the usefulness of sneakernet. For the rest who are unaware, this is basically comprised of adding your data to media storage (these days, probably a USB drive) and physically walking it over to where it needs to be. When services are down, it remains the most consistently reliable workaround. To use this method with Git, first we initialize a bare repo on our media:

cd /media/usb
git init --bare repo.git

Then, we can add this path as a remote to push to:

cd ~/src/repo
git remote add usb-stick /media/usb/repo.git
git push usb-stick main

Finally, we unmount the USB and bring it to the target machine and run the same setup before pulling:

cd ~/src/repo
git remote add usb-stick /media/usb/repo.git
git pull usb-stick main

Now, in order to sync later, the chosen media can be passed back and forth as your temporary central repository. If you only need to pass a repository and not later share history, an even simpler cudgel is available. With the above example, `/media/usb/repo.git` is effectively a copy of `~/src/repo/.git`. It would also be possible to simply:

cp -r ~/src/repo/.git /media/usb/repo.git

Then, on the target machine:

mkdir ~/src/repo
~/src/repo/
cp -r /media/usb/repo.git ~/src/repo/.git
git reset --hard

At this point, you have a carbon copy of the history and a working source directory. Perhaps even a bit better than the prior solution for initial sharing, because this method would share all branches on the source machine as well, instead of needing to individually push the same branches.

Option 2 - Direct peer-to-peer over local IP

It's also possible with a bridge, hotspot, or even just direct connection to do this over a two terminal network. In this example, we will assume that the source computer has an IP of 192.168.1.10 on this network. It's important to preface this by stating: don't do this outside of an isolated network, as this makes your served repo readable to anyone on your network. It's the sort of solution meant for long car rides and international flights, not general use. On our source machine:

# Make our service path
mkdir -p /srv/git && cd /srv/git

# Init a bare repo
git init --bare repo.git

# Add this local repo to your remotes; like the USB method, we can simply use the path
cd ~/src/repo
git remote add local /srv/git/repo.git
git push local main

# Return to the service path and launch the git daemon
cd /srv/git
git daemon --base-path=. --export-all --reuseaddr --verbose --port=9418

This invokes a lightweight, read-only service daemon that is built into Git, running on Git's default port of 9418. It requires no authentication, which is fine for our very small, isolated network. Then, our target can clone directly from this repository:

cd ~/src
git clone git://192.168.1.10/repo.git

Best practices would have both machines running their own daemon, committing and pushing to their local path and each machine pulling from each other. If it's more desirable however, one can also have our source machine act as a central authority. Again, not to be used outside an isolated network, and with additional peril, that this method would allow not only readability to everything on the network, but writability as well.

# Before running `git daemon`:
cd /srv/git/repo.git
git config receive.denyCurrentBranch ignore # `warn` is also an option in place of `ignore`
cd /srv/git

# Note the addition of --enable=receive-pack
git daemon --base-path=. --export-all --reuseaddr --verbose --port=9418 --enable=receive-pack

Option 3 - With SSH transport (most realistic for an office or VPN setting)

If sshd is available, changes can be pushed directly using SSH without running any daemon. Note for MacOS: enable Remote Login in System Settings -> General -> Sharing -> Advanced -> Remote Login For Linux: systemctl start sshd (assuming the sshd package is available) For Windows: You will require WSL, then installing the relevant package (most distros use the package openssh-server) and then port forwarding. This is beyond the scope of this guide, but it should be searchable, knowing what to look for. This will also likely require permissions handling, also beyond the scope of this guide. For Linux, search for how to add users and ssh public keys and group permissions with chmod or setfacl. As before, we will set up a directory for our repo and push to it normally:

# Make our service path
mkdir -p /srv/git && cd /srv/git

# Init a bare repo
git init --bare repo.git

# Add this local repo to your remotes; like the USB method, we can simply use the path
cd ~/src/repo
git remote add local /srv/git/repo.git
git push local main

Then, for our target machine, we can clone directly as if a path over SSH:

git remote add machine1 ssh://user@192.168.1.10/srv/git/repo.git
git pull machine1 main

If you wish to learn about a more retro way of creating patch files (the method of choice for collaboration over email), I suggest looking into the official documentation:

[table id=11 /] [post_title] => Gitting Good - How to Collaborate Without a Central Service [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => gitting-good-how-to-colabborate-without-a-central-service [to_ping] => [pinged] => [post_modified] => 2026-08-13 14:10:48 [post_modified_gmt] => 2026-08-13 14:10:48 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5268 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [2] => WP_Post Object ( [ID] => 5264 [post_author] => 7 [post_date] => 2026-06-25 16:57:23 [post_date_gmt] => 2026-06-25 16:57:23 [post_content] => There's a version of AI adoption in IT ops that looks something like this: someone buys a Copilot license, attaches it to ServiceNow, and waits for the magic to happen. Three months later, the tickets are still messy, the on-call engineer is still waking up at 2 am, and nobody can explain why the AI recommended closing an incident that was still actively on fire. We've seen this pattern more times than we can count. And it's not a technology problem, it's an approach problem. The Gap Between "AI-Capable" and "AI-Useful" Infrastructure and operations teams aren't short on tools. Most have 150% of the tools they need. They have observability stacks, ITSM platforms, runbook documentation, and CI/CD pipelines generating telemetry constantly. The problem is that nobody has connected those data sources to an AI workflow in a way that actually reflects how the team works. One of our clients - a regional financial services firm - managing roughly 400 VMs across a hybrid AWS and on-prem footprint came to us after spending six months trying to get Azure OpenAI to summarize their PagerDuty alerts in a useful way. The summaries were technically accurate but operationally useless. They'd describe what happened with perfect clarity and say nothing about the why, and nothing about what the on-call engineer should do about it at midnight. The root cause wasn't the model. It was that nobody had connected the alert data to the runbooks, to the CMDB topology, or to the historical incident record, or the knowledge base. The AI was operating without context like asking a new hire to triage production issues on their first day without showing them the architecture diagram. What The Three Days of Workshop Actually Looks Like Our AI Enablement Workshop is a three-day, hands-on engagement. Not a training. Not a slide deck. We come in, work directly with your tools and your data, and leave with working prototypes and a prioritized roadmap. Day one is mostly listening. We sit with the platform engineering team, the SRE leads, and often someone from security. We ask a lot of questions about where the pain actually lives - not the official answer, but the real one. Alert fatigue is almost always on the list. So is the runbook problem. Most teams have documentation that's six months out of date (sometimes years out of date) and written in a way that only the person who wrote it can interpret quickly under pressure. We also audit data readiness. This is where most AI projects quietly fall apart. A Tier 2 incident with three lines of description and no attached logs is not a useful training signal. We look at what's actually in your ITSM system, what observability data can be queried, and whether the runbooks are in a format that a retrieval-augmented AI can actually use. Day two is where we build. Typically, we develop two or three use cases. The specific mix depends on what the team needs most. The most common starting point is an Incident Copilot: an AI-powered assistant that, when a P1 fires, automatically pulls the relevant alerts, correlates them with recent change activity, surfaces the most applicable runbook section, and produces a structured incident summary that goes directly into the ticket. For one manufacturing client, this took the average time-to-context – i.e. the point at which the on-call engineer actually understands what they're dealing with, from 18 minutes down to under 4. That's not a vendor benchmark. That's a number their SRE lead pulled from incident records after 4 weeks in production. We also commonly build a Runbook Assistant - a natural language interface over internal operational documentation. Engineers type a question in plain English, like "what do we do when the payments service is throwing 503s from the ALB?" And get a synthesized, sourced answer from the actual runbooks, not a hallucinated guess. The key engineering challenge here is retrieval quality and chunking strategy. Getting that wrong is what produces the confident-sounding wrong answers that erode trust in AI tools. Another key point to take away is that developing habits for optimizing tokens will help with making these tools cost efficient. Day three is architecture and roadmap. Where does this go in production? How does it connect to Teams or Slack for alert delivery? What are the human approval controls? What does the security and governance boundary look like, and who owns the ongoing prompt maintenance? Frankly Speaking Not every team is ready for day two on day one. We've walked into environments where the runbooks are in a SharePoint folder that hasn't been touched in two years, or where the observability data is rich but structured in a way that requires significant preprocessing before it's useful as AI context. That's fine, since part of what the workshop produces is clarity on what has to happen before scaling, not just what can be built right now. We also don't recommend automating things that shouldn't be automated yet. Ticket enrichment – i.e. automatically classifying, tagging, and augmenting incoming tickets before a human reviews them - is a very different risk profile from automated ticket resolution. We help teams think through that boundary clearly, and we're direct when we think a client is moving faster than their governance posture supports. What You Walk Away With After three days, teams have working prototypes built against their own data, a reusable codebase and prompt library, an architecture blueprint for production deployment, and a 30/60/90-day roadmap with use cases prioritized by effort versus operational impact. More practically, they have a team that has actually built something with AI, and not just watched a demo. They have a concrete sense of what AI can and cannot do in their environment. That last part matters more than people think. The biggest barrier to AI adoption in infrastructure operations isn't budget or tooling. It's the lack of a shared mental model across the team for what AI is actually good at and how to work with it. The workshop builds that model by doing, not by describing. Keyva delivers the AI Enablement Workshop for Infrastructure and Operations as a fixed-price, three-day engagement. If you're evaluating where AI can have the most immediate impact for your ops team, reach out at info@keyvatech.com. [table id=3 /] [post_title] => When AI Actually Works in IT Operations — And Why Most Teams Are Doing It Wrong [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => when-ai-actually-works-in-it-operations-and-why-most-teams-are-doing-it-wrong [to_ping] => [pinged] => [post_modified] => 2026-06-25 16:57:23 [post_modified_gmt] => 2026-06-25 16:57:23 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5264 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [3] => WP_Post Object ( [ID] => 5257 [post_author] => 7 [post_date] => 2026-06-11 09:37:02 [post_date_gmt] => 2026-06-11 09:37:02 [post_content] =>

Keyva is pleased to announce the certification of the Keyva BMC Atrium Data Pump v2.0.1 for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Yokohama, Xanadu) to the Zurich release.

The ServiceNow Zurich release delivers enhanced AI-driven workflows, improved user experiences, and expanded automation capabilities to increase productivity, resilience, and service efficiency across the enterprise.

Keyva's BMC Atrium Data Pump v2.0.1 provides synchronization of CIs, CI attributes, and relationships from the ServiceNow CMDB into the BMC Atrium CMDB. This integration allows organizations to leverage their existing investment in Enterprise Software and avoid costly "Rip and Replace" projects.

Learn more about the Keyva BMC Atrium Data Pump and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

Keyva is pleased to announce the certification of the Keyva HP Universal CMDB Data Pump for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Yokohama, Xanadu) to the Zurich release.

Keyva's HP Universal CMDB Data Pump provides synchronization of CIs, CI attributes, and relationships between the ServiceNow CMDB and the HP Universal CMDB. This integration allows organizations to leverage their existing investment in Enterprise Software and avoid costly "Rip and Replace" projects.

Learn more about the Keyva HP Universal CMDB Data Pump and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva HP Universal CMDB Data Pump Certified for Zurich Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-hp-universal-cmdb-data-pump-certified-for-zurich-release [to_ping] => [pinged] => [post_modified] => 2026-06-10 20:36:53 [post_modified_gmt] => 2026-06-10 20:36:53 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5258 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [5] => WP_Post Object ( [ID] => 5256 [post_author] => 7 [post_date] => 2026-06-09 02:03:13 [post_date_gmt] => 2026-06-09 02:03:13 [post_content] =>

Keyva is pleased to announce the certification of the Keyva BMC Atrium Data Pump v3.2.1 for the new ServiceNow Zurich release. Clients can now seamlessly upgrade their ServiceNow App from previous ServiceNow releases (Yokohama, Xanadu) to the Zurich release.

Keyva's BMC Atrium Data Pump v3.2.1 provides synchronization of CIs, CI attributes, and relationships from the BMC Atrium CMDB into the ServiceNow CMDB. This integration allows organizations to leverage their existing investment in Enterprise Software and avoid costly "Rip and Replace" projects.

Learn more about the Keyva BMC Atrium Data Pump and view all the ServiceNow releases for which Keyva has been certified at the ServiceNow Store: store.servicenow.com.

[post_title] => Keyva BMC Atrium Data Pump Certified for Zurich Release [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => keyva-bmc-atrium-data-pump-bmc-to-servicenow-certified-for-zurich-release [to_ping] => [pinged] => [post_modified] => 2026-06-09 02:03:13 [post_modified_gmt] => 2026-06-09 02:03:13 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5256 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [6] => WP_Post Object ( [ID] => 5248 [post_author] => 15 [post_date] => 2026-06-01 15:09:46 [post_date_gmt] => 2026-06-01 15:09:46 [post_content] => Cloud environments grow fast, and so do bills. Without deliberate optimization, organizations routinely overspend by 20–40% on infrastructure that sits idle, is over-provisioned, or lacks lifecycle automation. The complexity of multiaccount, multi-cloud environments makes it nearly impossible to manage costs manually.

30%+ average cloud waste in enterprise environments
60% average cloud waste in enterprise environments
$20K monthly average savings Keyva delivers per engagement

The Keyva Cloud Cost Optimization Sprint

A Keyva Cloud Cost Optimization Sprint is a pre-scoped, fixed-price engagement designed to identify, prioritize, and implement cloud cost savings across your environment, and delivered in a structured 6-week sprint with clear, measurable outcomes. What’s Included: Week 1–2 Discovery & Audit Week Full cloud environment audit across all accounts/subscriptions. Inventory of all compute, storage, network, and managed services. Cost breakdown by service, team, environment (dev/test/prod), and tag. Identification of unused, idle, and over-provisioned resources. Deliverable: Cloud Cost Audit Report with full resource inventory and cost attribution map. 3–4 Analysis & Roadmap Right-sizing analysis and recommendations for compute instances and databases. License optimization review (reserved instances, savings plans, committed use). Automation gap assessment for resource lifecycle management. Prioritized savings roadmap with impact matrix. Deliverable: Cost Optimization Roadmap with prioritized recommendations and projected savings by item. Week 5–6 Implementation Implementation of top-priority quick wins (examples): right-sizing of flagged resources, tagging enforcement, budget alerts and automated shutdown policies for dev/test environments, infrastructure-as-code updates for identified patterns. Deliverable: Implemented changes with before/after cost comparison report and runbook for ongoing governance.

Cloud Cost Audit Report: Full inventory, cost attribution, and waste identification across all cloud accounts.
Cost Optimization Roadmap: Prioritized recommendations ranked by projected savings and implementation effort.
Implemented Quick Wins: Hands-on changes including right-sizing, lifecycle automation, and budget alerting.
Before/After Savings Report: Quantified cost reduction with month-over-month comparison.
Governance Runbook: Documented processes and IaC templates for ongoing cost discipline.

Case Study: A Keyva client running workloads across eight Azure subscriptions was spending approximately $180,000 per month on cloud infrastructure. Their leadership requested a cost review. Within six weeks, Keyva’s team used tagging strategies to break down cost allocations by environment, identified over-provisioned resources, implemented lifecycle automation, bundled licensing, and configured budget-based alarms. Result: $20,000 per month in sustained savings — an 11% reduction with a payback period under 2 months. Why Keyva

Cloud-Native Expertise: Proven, hands-on experience across AWS, Azure, and Google Cloud, grounded in infrastructure-as-code and FinOps methodologies.
Pre-Scoped for Predictability: Defined scope and transparent pricing ensure predictable outcomes with no scope creep or billing surprises.
Execution-First Approach: Keyva delivers implemented solutions, not just recommendations. Measurable savings begin during the engagement

[post_title] => Workshops & Assessments: Cost Optimization [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => cost-optimization [to_ping] => [pinged] => [post_modified] => 2026-06-01 15:43:30 [post_modified_gmt] => 2026-06-01 15:43:30 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5248 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) [7] => WP_Post Object ( [ID] => 5246 [post_author] => 15 [post_date] => 2026-06-01 15:02:09 [post_date_gmt] => 2026-06-01 15:02:09 [post_content] => CI/CD pipelines are the foundation of modern software delivery, yet most evolve incrementally under delivery pressure without a structured review against best practices. Over time, this results in slow build times, fragile deployments, security gaps, and escalating infrastructure costs. Keyva’s Pipeline Assessment and Optimization solution delivers a structured, expert led evaluation of your CI/CD pipeline portfolio and produces a prioritized, actionable optimization roadmap in three weeks or less.

Assessment Approach

The engagement follows a proven three phase methodology: discovery, analysis, and executive readout. Keyva engineers work directly with your teams, reviewing repositories and pipeline configurations in place and benchmarking your current state against industry best practices across more than ten critical domains. Each engagement evaluates pipelines across the following capability areas: Version control practices, pull request and merge workflows, CI pipeline structure, CD and deployment processes, GitOps practices, pipeline security, testing strategy, pipeline quality, standardization, collaboration and ownership, infrastructure, performance, and observability.

Supported Platforms

The assessment supports a broad range of leading CI/CD platforms commonly used across modern development environments, ensuring relevance regardless of tooling choices. CI/CD Technologies: GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps Pipelines, Google Cloud Build, CircleCI, Bitbucket Pipelines, TeamCity, Harness, Argo CD, Flux CD, Tekton, and AWS CodePipeline.

Scope of Engagement

The engagement is delivered through a structured, phased approach designed to provide rapid insight, actionable recommendations, and clear alignment across engineering, platform, and security teams. Discovery and Inventory This phase establishes a clear, shared understanding of the current pipeline landscape and developer experience.

Stakeholder alignment with engineering, platform, and security leads
Comprehensive inventory of repositories and pipelines across all platforms
Developer experience survey to identify friction points and bottlenecks
Toolchain and integration mapping, including CAs, secrets, artifact registries, and SIEM
Baseline metric collection covering build duration, failure rates, MTTR, and cost per build

Deliverable: Complete pipeline inventory, baseline metrics, and confirmed assessment scope.

Pipeline Analysis

This phase delivers a deep technical and operational evaluation of pipelines across all assessment domains.

Detailed review of all assessment categories for each CI/CD platform
Security focused analysis including secrets handling, OIDC usage, software supply chain risks, and dependency scanning
GitOps and infrastructure as code pipeline review covering Terraform, Ansible, and Helm
Standardization gap analysis across teams and repositories
Up to four structured interviews with platform teams to validate findings

Deliverable: Comprehensive findings matrix and validated interview readouts with the platform team. Optimization and Roadmap Handover This phase translates findings into an executable plan aligned to business and engineering priorities.

Effort and impact based prioritization of all recommendations
Phased implementation roadmap highlighting quick wins and strategic improvements
Executive summary and readout presentation
Full written assessment report
Optional two week follow up check in to support execution momentum

Deliverable: Assessment report, executive readout deck, and implementation roadmap.

Outcome

Keyva’s Pipeline Assessment and Optimization solution delivers measurable operational, security, and cost improvements across the software delivery lifecycle.

Faster Software Delivery: Reduce average build times by 30–50 percent through caching, parallelization, and stage optimization, increasing deployment velocity
Reduced Security Risk: Eliminate credential exposure, secret sprawl, and supply chain vulnerabilities before they become incidents or audit failures
Recovered Engineering Capacity: Free developers from pipeline instability, manual fixes, and on call interruptions, redirecting time toward feature and platform work
Audit Ready CI/CD Controls: Establish documented, enforceable standards that support compliance and governance requirements
Lower Infrastructure Costs: Right size CI/CD compute resources and eliminate redundant or uncached build steps
A Scalable Pipeline Foundation: Replace bespoke, fragile scripts with reusable templates and standards that scale without accruing technical debt

[post_title] => Workshops & Assessments: Pipeline Assessment and Optimization [post_excerpt] => [post_status] => publish [comment_status] => closed [ping_status] => closed [post_password] => [post_name] => pipeline-assessment-and-optimization [to_ping] => [pinged] => [post_modified] => 2026-06-01 15:43:40 [post_modified_gmt] => 2026-06-01 15:43:40 [post_content_filtered] => [post_parent] => 0 [guid] => https://keyvatech.com/?p=5246 [menu_order] => 0 [post_type] => post [post_mime_type] => [comment_count] => 0 [filter] => raw ) ) [post_count] => 8 [current_post] => -1 [before_loop] => 1 [in_the_loop] => [post] => WP_Post Object ( [ID] => 5281 [post_author] => 15 [post_date] => 2026-08-13 13:22:46 [post_date_gmt] => 2026-08-13 13:22:46 [post_content] => Git has a feature to help hunt down bugs for a very specific sort of problem: when you have a regression, but you don't know when it was introduced. This feature, known as `bisect`, can assist is tracking down such an issue by running a binary search through a repository's history to find the exact commit that such a regression was introduced.

Basic setup

# To initialize
git bisect start

# Declaring the current commit as broken; a tag or commit hash can also be included if an earlier broken commit is already known
git bisect bad

# Declaring a specific tag as a working commit; specific commit hashes may again be used
git bisect good v1.2.0-release

# If the checkout has the bug:
git bisect bad

# Or if it does not:
git bisect good

# Or, if there is something preventing testing with this specific commit:
git bisect skip

Workflow Considerations

Automation

Good practices with workflow can also allow for ease of automation. Having a test suite that can determine if a commit is good or not can assist greatly. This can be done via exit codes:

0 for a successful run (indicating good)
A value between 1 and 124 or 126 or 127 for a failed test (indicating bad)
A value of 125 if a build failed (indicating skip)
Any other value to abort the bisect process

This test need not be a part of the repo itself, so any new testing that needs to be done won't need to interfere with multiple checkouts. To start automated tests, we begin in much the same way:

git bisect start
git bisect bad
git bisect good v1.2.0-release

# To declare how to test automatically:
git bisect run ~/tests/run-test.sh # or wherever your script is

Tests can be done inline as well. This is useful for many functions, with perhaps the best example being scanning output for a specific message or message fragment:

git bisect run bash -c '/usr/bin/env python3 main.py arg1 arg2 | grep -q "ERROR"'

Finally, using worktree, a specific current and committed test suite can also be defined, allowing checkouts of running code while leaving the most current tests intact:

git worktree add ../bisect-tests HEAD
git bisect run ../bisect-tests/tests/run.sh

Other uses

Finding when a performance issue began
Finding when a function or feature was added to the repo (with run grep -q)
Finding when CI pipelines began failing
Finding when a security vulnerably was introduced
Detecting when code coverage degraded

Get Appointment

Blog & Insights

Basic setup

Workflow Considerations

Automation

Other uses

Option 1 - Bare repo on shared media

Option 2 - Direct peer-to-peer over local IP

Option 3 - With SSH transport (most realistic for an office or VPN setting)

The Keyva Cloud Cost Optimization Sprint

Assessment Approach

Supported Platforms

Scope of Engagement

Pipeline Analysis

Outcome

Basic setup

Workflow Considerations

Automation

Other uses

When VMware Stopped Being the Safe Choice

Gitting Good – Using Bisect – Git’s Built-in Debugging Tool

Gitting Good – How to Collaborate Without a Central Service

When AI Actually Works in IT Operations — And Why Most Teams Are Doing It Wrong

Keyva BMC Atrium Data Pump Certified for Zurich Release

Keyva HP Universal CMDB Data Pump Certified for Zurich Release

Keyva BMC Atrium Data Pump Certified for Zurich Release

Workshops & Assessments: Cost Optimization

Workshops & Assessments: Pipeline Assessment and Optimization

Get In Touch