|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
In this podcast, Shane Hastie, Lead Editor for Culture & Methods, spoke to Satish Kothapalli about the transformative impact of AI and vibe coding in life sciences software development, the acceleration of drug development timelines, and the evolving roles of developers in an AI-augmented environment.
By Satish Kothapalli
If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that, and need to solve database performance problems quickly. You can also get a quick, low cost health check with no phone time required.
The post Why DISKANN Indexes Are So Slow To Create In SQL Server appeared first on Darling Data.
This image is from 2010, and it goes along with my last post of what our Customers Say about us. However, this is what our employees said about the company.
At this point we would have been around a 200 person company, mostly in the UK. It’s a great list of words, and if I were looking for a new employer, this type of work cloud might get me interested in applying.
Redgate has often felt like an extended family, where we care about each other, we’re bonded, and we’re working together to get through life. We disagree and bicker at times, but we love each other.
We’re now closer to a 600 person company, and I don’t know that all of us, or even most of us, feel the same ways, but I’d like to think most people still think this is a great place to work.
I do.
I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.
The post The Book of Redgate: What Our Staff Says appeared first on SQLServerCentral.
This article was brought to you by Rajkumar Venkatasamy, draft.dev.
Jenkins is still one of the most popular tools for continuous integration and delivery (CI/CD). People love it for its flexibility, vast plugin ecosystem, and the fact that it’s open source. It can automate just about any build, test, or deployment you throw at it, but that flexibility comes with a catch: configuration drift.
Configuration drift happens when someone makes changes through the Jenkins user interface (UI) (often referred to as “click-ops”) that don’t get reflected in the code, such as Jenkinsfiles for pipelines, Job DSL scripts for job definitions, or YAML files in Jenkins Configuration as Code (JCasC). Over time, these discrepancies create inconsistencies across environments, making it hard to reproduce builds, ensure compliance, or recover from disasters.
Configuration drift happens when someone makes changes through the Jenkins user interface (UI) (often referred to as “click-ops”) that don’t get reflected in the code.
Imagine this scenario: A developer tweaks a job’s build retention policy in the UI to debug an issue, but forgets to update the corresponding Job DSL script. In production, this leads to unexpected disk usage spikes, while dev and test environments behave differently because they’re still using the original retention settings (e.g. ten builds).
This kind of drift undermines the whole point of DevOps. It erodes trust; what’s in version control no longer matches reality. If you’re dealing with compliance requirements (like SOC 2 or GDPR), you’ve got audit problems because there’s no trail for these changes. And when disaster strikes and you need to rebuild your Jenkins controller, you might get your data back, but not the drifted configs. Cue the downtime.
In this guide, you’ll learn how to manage and eliminate configuration drift in your Jenkins setup. We’ll cover how to baseline what you’ve currently got, codify configurations, enforce access controls, and implement continuous detection and remediation.
By the end, you’ll have tools and strategies to maintain a single source of truth and a Jenkins setup that’s actually reproducible and auditable. This guide assumes that you have prior DevOps experience, particularly in installing and managing Jenkins.
Managing configuration drift requires a systematic approach: Observe what’s required as part of the CI/CD pipeline, codify everything possible, prevent unauthorized changes, and monitor for deviations. Each step builds on the last, emphasizing why it matters for auditability (tracking who did what) and reproducibility (ensuring configs can be recreated reliably from code).
To tackle configuration drift, you need a clear picture of your Jenkins environment’s current state. A baseline establishes a single source of truth for reproducibility, while ongoing monitoring provides auditability, revealing who changed what and when. After baselining, you can use tools to monitor changes and detect drift.
Start by exporting your Jenkins controller’s configuration using the JCasC plugin. If the plugin isn’t installed, add it via Manage Jenkins | Manage Plugins, search for “Configuration as Code”, and install it (no restart required).
Then, use the Jenkins CLI to export the current configuration to a YAML file, which captures core settings, plugins, security, and more. Run this command from a terminal with the Jenkins CLI JAR:
java -jar jenkins-cli.jar -s http://localhost:8080/ -auth:your_admin_user:your_admin_password export-configuration > jenkins.yaml
This jenkins.yaml file is your baseline. It reflects the exact state of your Jenkins instance at this moment. This snapshot lets you compare against future configurations to quantify drift, ensuring you can revert to or rebuild this state for disaster recovery or reproducibility across environments.
With the baseline captured, you’ll need to install the Job Configuration History plugin to act as your “drift radar”. This plugin tracks changes to jobs, views, and system configurations, logging diffs that show who modified what and when.
Navigate to Manage Jenkins | Manage Plugins, look up Job Configuration History, and install it. Once that’s installed, you can access it via Manage Jenkins > Job Config History to view a history of changes, including diffs in XML format.
For example, if someone later changes a job’s executor label or build retention policy via the UI, the plugin shows the before-and-after XML, highlighting the drift from your coded configurations (e.g. Job DSL or Jenkinsfiles).
Review these diffs weekly to spot unauthorized or undocumented changes. This provides an audit trail for compliance (e.g. who made a change for SOC 2 audits) and helps identify patterns, like frequent UI edits, that indicate where drift originates.
You can use the exported Jenkins YAML file to transition your Jenkins controller configuration to a code-based approach using the JCasC plugin. This plugin lets you define Jenkins’s global settings, security, agents, and plugins in YAML, which can be stored in Git for version control and auditability.
On startup, Jenkins loads this YAML, overwriting any UI changes. It enforces a single source of truth in version control, where changes go through pull requests (PRs) for review. This makes configs auditable and reproducible across environments.
Store the YAML in a Git repo, and set the environment variable CASC_JENKINS_CONFIG to point to it (e.g. a file path or Git repo URL of the YAML file). A snippet from this YAML might look like this:
Log in
configuration-as-code: {
}
credentials:
folder: {
}
providerImpl: {
}
system:
domainCredentials:
- domain: {
}
user: {
}
jenkins:
authorizationStrategy:
loggedInUsersCanDoAnything:
allowAnonymousRead: false
..
..
..
securityRealm:
local:
allowsSignup: false
enableCaptcha: false
users:
- id: "admin"
name: "admin"
…
…
…
tool:
git:
installations:
- home: "git"
name: "Default"
mavenGlobalConfig:
globalSettingsProvider: "standard"
settingsProvider: "standard"
Notice that the exported configuration includes a credentials section for defining secrets. Make sure you keep secret values out of source control by referencing environment variables or using JCasC’s credentials section with external providers like HashiCorp Vault.
Note: You need to have the HashiCorp Vault plugin installed and configured in your Jenkins for this to work.
For instance, the credentials section needs to be configured similarly to the one below to map the secret from HashiCorp Vault:
credentials:
system:
domainCredentials:
- credentials:
- vaultTokenCredential:
description: "My Secret"
id: "MY_SECRET"
scope: GLOBAL
token: "${MY_SECRET_TOKEN}"
This separation ensures sensitive data isn’t committed, maintaining security while keeping configs versioned. If you want to learn more about how to handle secrets, check out this JCasC plugin.
Jobs and pipelines are prime drift culprits; UI-based tweaks can easily diverge from versioned code. You can use the Job DSL plugin to define and generate Jenkins jobs programmatically using Groovy scripts. This plugin treats job configurations as code, so you can automate them, version them, and manage hundreds of jobs without clicking through the UI.
When you regenerate jobs from the DSL, it overwrites any manual changes, keeping everything consistent.To get started with Job DSL, install the plugin via Manage Jenkins | Manage Plugins, search for “Job DSL”, and install it:
The seed job is central to the Job DSL plugin’s workflow. It serves as a special freestyle or pipeline job that executes your Groovy DSL scripts to dynamically create or update other jobs.
The seed job acts as an entry point: It pulls the DSL scripts from version control (e.g. Git) and processes them to generate the target jobs. A seed job lets you automate job creation at scale, making it ideal for managing dozens or hundreds of jobs consistently.
If you want to learn more about how to define and make use of seed jobs, check out this official documentation. For pipelines, use Jenkinsfiles in your application repositories to define declarative or scripted pipelines. These are loaded directly from SCM during job execution, further reducing UI reliance:
// Jenkinsfile
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building...'
}
}
}
}
As your CI/CD setup grows, shared libraries help handle the complexity. They’re best when multiple pipelines need to reuse common logic like authentication steps, deployment workflows, or utility functions. These help you avoid code duplication across Jenkinsfiles.
Without shared libraries, duplication increases maintenance overhead, risks inconsistencies, and encourages UI overrides for quick-fixes. Shared libraries centralize reusable Groovy code in a separate Git repository, promoting the principles of DRY (don’t repeat yourself) and discouraging ad hoc UI changes.
Preventing configuration drift is critical to maintaining reproducible, auditable, and compliant Jenkins environments. You can use the Matrix Authorization Strategy plugin to control who can perform UI edits.
Make sure you only grant “Configure” permissions to a small admin group. This helps prevent accidental or unauthorized click-ops and forces changes to be made through code paths that are reviewable and auditable. For read-only access, use the Extended Read plugin.
Define the authorization configuration using these Matrix Authorization Strategy and Extended Read plugins in jenkins.yaml, like this:
jenkins:
authorizationStrategy:
globalMatrix:
permissions:
- "Overall/Administer:admin-group"
- "Job/Configure:admin-group"
- "Overall/Read:everyone"
- "Job/Read:everyone"
This jenkins.yaml configuration defines the authorization strategy for the Jenkins instance, specifically implementing a global matrix security model for access control. It establishes a set of permissions for different users or groups. The configuration grants the admin-group both the highest level of administrative access, indicated by "Overall/Administer", and the ability to configure jobs, shown by "Job/Configure".
Simultaneously, it ensures that everyone (meaning any user) has basic read access to the Jenkins overall status and to individual jobs, represented by "Overall/Read" and "Job/Read", respectively. Essentially, it creates a system where only the designated administrator group can manage and configure Jenkins, while all other users can view the system and its jobs.
Even with specific guardrails like matrix authorization restricting UI edits to admins, configuration drift can still occur in subtle ways. For instance, admins might make legitimate but undocumented UI changes during urgent debugging (e.g. temporarily increasing build retention for troubleshooting); to prevent drift, codify these changes in Job DSL or JCasC or revert them after resolving the issue.
Plugin updates can introduce default settings that override existing configurations if not pinned in code. External factors, like agent failures prompting ad hoc label changes or third-party integrations (e.g. a GitHub webhook tweak), can also introduce discrepancies. In multi-user environments, even with read-only access enforced, shared credentials or misconfigured roles might allow indirect changes via scripts or APIs.
These scenarios highlight why proactive monitoring is necessary. Drift often stems from human oversight or system events, not malice, but they erode reproducibility and auditability if unchecked.
Monitor Job Configuration History diffs and script comparisons (e.g. check export job XML and diff against the job’s DSL). If drift is detected, revert via JCasC reload or codify the change in Git. For mass remediation, use the Configuration Slicing plugin to align settings across multiple jobs (i.e. build discarders, labels, or email notifications).
This plugin enables “slicing” by category (e.g. all discard-old-builds settings), selecting jobs, and applying uniform values, then capturing the result in DSL/JCasC to prevent recurrence. It restores consistency quickly for large-scale drift (e.g. after a plugin update affects over fifty jobs) while promoting code-based baselines for long-term prevention.
When it comes to managing configuration drift in Jenkins, treat Jenkins like your apps. Lint JCasC YAML with tools like yamllint in PR pipelines, and validate Job DSL with a Groovy linter. Synchronize plugin updates with config as code. Use the Plugin Installation Manager Tool to define plugins in JCasC:
plugins:
- artifactId: git
source:
version: latest
- artifactId: "mailer"
source:
version: "1.32"
Plugins affect configs; make sure you version them for rollbacks to ensure auditability.
Monitoring Jenkins with Prometheus and Grafana helps you track config-related metrics, like job change frequency, so you can spot configuration drift early and keep your CI/CD environment reproducible. After installing the Prometheus Metrics Plugin in Jenkins, metrics like job configuration changes (tracked via the Job Configuration History plugin) or build-related data become available at an endpoint like http://localhost:8080/prometheus.
Grafana integrates with Prometheus to visualize these metrics in dashboards, letting you graph job change frequency over time or filter by job or user. For example, a query like jenkins_job_config_changes_total{job="DemoJob"} tracks how often DemoJob is modified. T
his setup requires configuring Prometheus to scrape Jenkins (via prometheus.yml), setting up Grafana with Prometheus as a data source, and creating dashboards with queries tailored to configuration events, ensuring continuous monitoring and rapid remediation of drift in your Jenkins.
By baselining with Job Configuration History and JCasC exports, codifying configurations via YAML and DSL, enforcing access controls with the Matrix Authorization Strategy plugin, and detecting/remediating issues with slicing and monitoring, you can build a split strategy for managing configuration drift in Jenkins. This approach helps establish a workflow where changes are versioned, reviewed, and reproducible.
That said, the plugins covered here require ongoing setup and maintenance. If you’re looking to remove this class of problems entirely, JetBrains TeamCity can help handle configuration versioning natively. TeamCity bakes “config in VCS” into the product with versioned settings and Kotlin DSL, including two-way sync that commits UI changes to Git (or one-way, read-only mode that disallows UI edits), validation before application, audit/history views, and tokenized handling of secure values.
Beyond configuration management, TeamCity also offers a more polished developer experience. If you’re curious about the day-to-day differences between Jenkins and TeamCity, check out our article “From Clunky to Clean: A UI/UX Comparison of Jenkins and TeamCity.” It walks through the practical UI/UX differences that impact productivity the most.
Whether you refine your Jenkins setup or migrate to a tool like TeamCity, you’ll achieve drift-free CI/CD, boosting team productivity and system reliability.
I gave the following talk at Microsoft Ignite 2025:
Connecting LLMs to your secure, operational database involves complexity, security risks, and hallucinations. This session shows how to build context-aware AI agents directly on your existing data, going from live database to production-ready, secure AI agent in hours. You'll see how to ship personalized experiences that will define the next generation of software. RavenDB's CEO will demonstrate this approach.
