What is an Audit Trail?
Audit trails are electronic records that chronologically catalog events related to operational procedure or change.
In the context of Continuous Delivery, it’s basically the who, what and when of all activity relating to the contents, dependencies, and execution of your deployment pipelines.
Why does Continuous Delivery need an Audit Trail?
Simply put, audit trails provide proof of compliance and operational integrity when it comes to how organizations deliver software and manage change.
Without audit trails, organizations would be blind to answering the most basic of questions like “Who did what when?”
For many financial and retail organizations, audit trails enable proof of compliance, and proof of compliance enables them to legally trade. It’s that simple.
In a typical enterprise, you might have 10s of business units, 100s of dev teams, and 1000s of software engineers. Keeping an accurate audit of who did what when is therefore not a trivial task given that every application, environment, and tech stack is different.
I’ve personally heard stories of developers in many organizations using kubectl to directly update production clusters on-the-fly using their laptop. Compliance and operational integrity this is not.
How does the Audit Trail work in Harness?
The Harness Audit Trail can be found under the Continuous Security navigation drop-down:
You should then see something like this (an audit trail of beauty):
In the above screenshot, the audit trail shows that I (Stephen Burton) created a new Service, Environment, Deployment Workflow, and Pipeline in just 3 minutes.
Harness basically captures and audits the timestamp, event source, resource and details of all user-level transactions (e.g. create, update, delete, execute, …)
Audit trails by default are persisted for one year.
Highlighting Diffs in Detail
Harness also audits and shows detailed differences for all updates.
For example, let’s say that I updated phase-2 of my canary deployment workflow from 50% of containers to 63%:
Harness would audit and log that change as follows:
Clicking on the “YAML Diff” icon (highlighted above) would then show the exact differences from the update:
As you can see, the audit trail confirms that phase-2 of my canary deployment was updated to 63% of containers from 50%.
This detailed diff audit view is available for any component or config (e.g. Kubernetes manifests, environment variables, triggers, …) within your deployment pipelines.
It’s pretty awesome!
Feel free to kick the tires with our free trial.