data-platform-ci-cd-and-release-management

Name: data-platform-ci-cd-and-release-management
Author: vaquarkhan

19stars4forks

How to install data-platform-ci-cd-and-release-management?

vaquarkhan/data-engineering-agent-skills/data-platform-ci-cd-and-release-management

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-platform-ci-cd-and-release-management

Installs into the current project.

Summary

Guides agents through CI/CD and release management for data platforms. Use when promoting pipeline code, SQL models, contracts, infra, or configuration across environments with validation gates, staged rollout, and rollback awareness.

Files · 1

View on GitHub

SKILL.md

1	# Data Platform CI CD And Release Management
2
3	## Overview
4
5	Use this skill when changes need controlled promotion across environments. It helps agents design release gates for code, contracts, infra, and datasets so teams can ship faster without losing trust.
6
7	## When to Use
8
9	- adding or changing CI pipelines for data projects
10	- promoting changes from dev to staging to production
11	- releasing `dbt`, orchestration, infra, or schema updates
12	- defining rollback-aware deployment behavior
13
14	Do not treat data releases like app-only deploys. Data contracts, backfills, and environment state matter too.
15
16	## Workflow
17
18	1. Identify the release surface.
19	Include:
20	- code
21	- SQL models
22	- infra
23	- contracts
24	- orchestration config
25	- published datasets
26
27	2. Define validation gates per stage.
28	Common gates:
29	- lint or formatting
30	- tests
31	- contract validation
32	- sample or shadow runs
33	- reconciliation
34
35	3. Separate deployment from publish where needed.
36
37	4. Make rollback and forward-fix expectations explicit.
38
39	5. Record release ownership and approval points for high-risk changes.
40
41	## Common Rationalizations
42
43	\| Rationalization \| Reality \|
44	\| --- \| --- \|
45	\| "If tests pass, the data release is safe." \| Data releases often need contract, reconciliation, and environment checks too. \|
46	\| "We can deploy and publish in one step." \| Deployment and downstream visibility should not always be coupled. \|
47	\| "Rollback is easy because Git exists." \| Rollback for data state and published outputs is often harder than code rollback. \|
48
49	## Red Flags
50
51	- environment promotion rules are unclear
52	- releases do not separate code success from publish safety
53	- rollback is mentioned but not operationally real
54	- high-risk changes have no staged validation
55
56	## Verification
57
58	- [ ] Release surfaces and environment boundaries are explicit
59	- [ ] Validation gates exist for the change type
60	- [ ] Publish behavior is controlled where needed
61	- [ ] Rollback or forward-fix expectations are documented

People who liked this also viewed

6 picks

Type

data-platform-ci-cd-and-release-management

19stars4forks

View on GitHub

How to install data-platform-ci-cd-and-release-management?

vaquarkhan/data-engineering-agent-skills/data-platform-ci-cd-and-release-management

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill data-platform-ci-cd-and-release-management

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Data Platform CI CD And Release Management
2
3	## Overview
4
5	Use this skill when changes need controlled promotion across environments. It helps agents design release gates for code, contracts, infra, and datasets so teams can ship faster without losing trust.
6
7	## When to Use
8
9	- adding or changing CI pipelines for data projects
10	- promoting changes from dev to staging to production
11	- releasing `dbt`, orchestration, infra, or schema updates
12	- defining rollback-aware deployment behavior
13
14	Do not treat data releases like app-only deploys. Data contracts, backfills, and environment state matter too.
15
16	## Workflow
17
18	1. Identify the release surface.
19	Include:
20	- code
21	- SQL models
22	- infra
23	- contracts
24	- orchestration config
25	- published datasets
26
27	2. Define validation gates per stage.
28	Common gates:
29	- lint or formatting
30	- tests
31	- contract validation
32	- sample or shadow runs
33	- reconciliation
34
35	3. Separate deployment from publish where needed.
36
37	4. Make rollback and forward-fix expectations explicit.
38
39	5. Record release ownership and approval points for high-risk changes.
40
41	## Common Rationalizations
42
43	\| Rationalization \| Reality \|
44	\| --- \| --- \|
45	\| "If tests pass, the data release is safe." \| Data releases often need contract, reconciliation, and environment checks too. \|
46	\| "We can deploy and publish in one step." \| Deployment and downstream visibility should not always be coupled. \|
47	\| "Rollback is easy because Git exists." \| Rollback for data state and published outputs is often harder than code rollback. \|
48
49	## Red Flags
50
51	- environment promotion rules are unclear
52	- releases do not separate code success from publish safety
53	- rollback is mentioned but not operationally real
54	- high-risk changes have no staged validation
55
56	## Verification
57
58	- [ ] Release surfaces and environment boundaries are explicit
59	- [ ] Validation gates exist for the change type
60	- [ ] Publish behavior is controlled where needed
61	- [ ] Rollback or forward-fix expectations are documented

People who liked this also viewed

6 picks

Type