Atlantis 架构决策记录（ADR）实践指南：从决策流程到 API 增强与漂移检测的实现落地

DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载本文以 Atlantis 仓库docs/adr/目录下的架构决策记录体系为核心完整讲解 ADR 的引入背景、触发条件、提交流程与状态管理并深入拆解其中最具技术分量的 ADR 0002API 增强与漂移检测结合当前仓库源码验证其在server/中的落地情况帮助读者掌握一套先记录决策、再按阶段实现的大型 Terraform 自动化项目演进方法论。1. 为什么 Atlantis 需要 ADR一个去中心化项目的决策共识机制Architecture Decision Records架构决策记录简称 ADR是一种用简短文档记录为什么做出某个架构决策及其取舍tradeoffs的轻量级实践。Atlantis 在 ADR 0001日期 2023-05-09状态 Accepted中正式采纳了这套机制其理由直接指向项目自身的组织特点项目高度去中心化a very decentralized project频繁出现一次性贡献者one-timer contributors维护者团队也在不断更替。通过 ADR 流程可以改进决策方式并把过往决策透明化帮助未来的贡献者与维护者自信地引导项目方向。核心观点在一个人来人往的开源项目中代码本身只会告诉做了什么而 ADR 负责记录为什么这样做、为什么不做另一个方案。仓库 docs/adr/README.md 明确引用 Michael Nygard 提出的 ADR 方法论Documenting Architecture Decisions作为决策模板的出处。2. ADR 目录结构与状态定义仓库的docs/adr/目录目前包含 4 个文件构成一套完整的决策档案文件作用docs/adr/README.md索引页登记全部 ADR 及提交流程、触发条件、状态定义docs/adr/0001-record-architecture-decisions.md第一条 ADR宣布采纳 ADR 机制Accepteddocs/adr/0002-api-enhancement-drift-detection.md第二条 ADR规划 API 增强与漂移检测Proposeddocs/adr/template.md新 ADR 的标准模板2.1 标准 ADR 模板结构模板文件 定义了每个 ADR 必须包含的四段式结构Title / Date编号加短标题# N. Short title并标注日期Date: YYYY-MM-DDStatus标注生命周期状态模板注释列出全部合法值Proposed、Accepted、Rejected、Superseded by NNNN、DeprecatedContext描述问题、约束与相关 issue只包含未来读者理解决策所需的信息Decision写明项目将做什么并简要记录被否决的严肃备选方案及原因Consequences列出收益与取舍重点标注迁移、兼容性破坏、或被本决策取代的旧 ADR。2.2 ADR 状态机README 为每个状态给出了精确定义Proposed讨论中Accepted已获项目批准Rejected经考虑后被否决Superseded by NNNN被后来的 ADR 取代Deprecated不再适用。两条管理规范值得特别强调这也是 README 明确写出的约定Accepted 与 Rejected 的 ADR 都要合入让两种决策都可被检索禁止事后改写只能通过新 ADR 覆盖supersedeADR 遵循常规的 Pull Request 评审规则已接受的 ADR 需要在其实现 PR 中链接对应 ADR。3. 什么变更必须写 ADR什么不需要README 用两张表格划清了边界这是理解 Atlantis 贡献流程的关键。3.1 选择处理流程变更类型处理流程Bug 修复、文档、测试、CI、依赖更新、保持行为不变的代码重构直接开 Pull Request新的用户可见行为、flags 或命令先在 issue 中达成共识再开 Pull Request符合下方 ADR 触发条件的变更开 issue → 提交 ADR → ADR 被接受后再实现一句话原则决策本身比 diff 大小更重要The decision matters more than the diff size。3.2 必须写 ADR 的触发条件当变更满足以下任一条件时必须先产出 ADR改变持久化数据、数据迁移或磁盘布局对 API、配置 schema、服务端 flag、默认值或 webhook 契约做出破坏性变更改变并发或锁locking行为新增必需的运行时服务、插件或扩展点改变认证、授权、密钥处理、命令执行或 webhook 校验变更不可逆或反转一条已被接受的 ADR。3.3 不需要写 ADR 的场景明确豁免的变更包括Bug 修复、纯增量可选字段、默认关闭的功能、行为不变的性能优化、重构、测试、文档、工具链、CI 与依赖升级。若拿不准README 给出的建议是在开始大型实现前先开一个 issue。4. 提交新 ADR 的完整流程按 docs/adr/README.md 的规定提交流程共 4 步先在 issue 中就问题达成一致复制 template.md 到docs/adr/NNNN-short-title.md编号取已合并 ADR 与在途 ADR PR中的下一个序号若先有其他 ADR 合并需重新编号以Proposed状态开 PR并同步更新 README 索引表表中的Update this table when adding or changing an ADR即指此约定。同时要求ADR 只聚焦于一个决策实现细节放到 issue 或实现 PR 中。5. 深度解析 ADR 0002API 增强与漂移检测的五个阶段ADR 0002日期 2025-01-21状态 Proposed是仓库中技术含量最高的一条 ADR它完整规划了 Atlantis API 从PR 驱动走向API 驱动 漂移检测 自动修复的演进路线。这条 ADR 提出的方案在当前仓库源码中已经大量落地非常适合作为理解 Atlantis API 架构的入口。5.1 背景现有 API 的五个痛点ADR 指出当前 API/api/plan、/api/apply、/api/locks存在五类问题错误序列化 BugGo 的error类型在 JSON 响应中会序列化成{}或null而不是真实的错误消息非 PR 工作流受限没有 PR 上下文的 API 调用会卡在approved已批准与mergeable可合并两个需求检查上导致漂移检测场景无法使用没有漂移检测无法在 PR 工作流之外发现基础设施漂移API 不稳定现有端点标记为 ALPHA随时可能变化功能有限缺少 projects、runs 与运维类端点。ADR 还记录了它对两个早期 PR 的分析结论PR #6093错误序列化目标是修复 error 字段序列化但其实现把ProjectResult从内嵌ProjectCommandOutput改成具名字段这会破坏 API 响应结构多出一层ProjectCommandOutput: {...}包装。ADR 给出的正确做法是在ProjectResult上实现自定义MarshalJSON保持内嵌结构不变、只把 error 转为字符串。PR #6095非 PR API 支持目标是在 API 直接 apply 时跳过approved/mergeable检查思路是给ProjectContext增加API标志当ctx.API ctx.Pull.Num 0时跳过 PR 专属需求。ADR 认可该方向但要求纳入整体设计。5.2 必须保持的 API 响应结构ADR 用一段 JSON 固定了/api/plan、/api/apply的响应骨架——任何增强都不能改变它Error为顶层指针、ProjectResults为扁平数组、每个项目结果字段平铺{ Error: null, Failure: , ProjectResults: [ { Error: null, Failure: , PlanSuccess: {...}, PolicyCheckResults: null, ApplySuccess: , VersionSuccess: , ImportSuccess: null, StateRmSuccess: null, Command: 1, SubCommand: , RepoRelDir: ., Workspace: default, ProjectName: , SilencePRComments: null } ], PlansDeleted: false }这份结构与仓库 server/events/command/project_result.go 中实际定义的ProjectResult完全对应——它确实通过内嵌ProjectCommandOutput包含Error error、Failure string、PlanSuccess、PolicyCheckResults、ApplySuccess、VersionSuccess、ImportSuccess、StateRmSuccess等字段保持平铺结构顶层 server/events/command/result.go 的Result则持有Error、Failure、ProjectResults []ProjectResult与PlansDeleted。ADR 中给出的自定义MarshalJSON方案匿名 struct 逐字段列举 errMsg *string指针转换正是为了在不动结构的前提下让 error 正确输出为字符串。5.3 Phase 1错误序列化修复向后兼容目标修复错误序列化同时不改变 API 响应结构。ADR 的完整实现方案包含两段代码// server/events/command/project_result.go func (p ProjectResult) MarshalJSON() ([]byte, error) { // 将 error 转为字符串指针保证可序列化 var errMsg *string if p.Error ! nil { msg : p.Error.Error() errMsg msg } // 用匿名 struct 控制 JSON 输出保持扁平结构 return json.Marshal(struct { Error *string json:Error Failure string json:Failure PlanSuccess *models.PlanSuccess json:PlanSuccess PolicyCheckResults *models.PolicyCheckResults json:PolicyCheckResults ApplySuccess string json:ApplySuccess VersionSuccess string json:VersionSuccess ImportSuccess *models.ImportSuccess json:ImportSuccess StateRmSuccess *models.StateRmSuccess json:StateRmSuccess Command Name json:Command SubCommand string json:SubCommand RepoRelDir string json:RepoRelDir Workspace string json:Workspace ProjectName string json:ProjectName SilencePRComments []string json:SilencePRComments }{ Error: errMsg, Failure: p.Failure, /* ...其余字段... */ }) } // server/events/command/result.go func (c Result) MarshalJSON() ([]byte, error) { type Alias Result var errMsg *string if c.Error ! nil { msg : c.Error.Error() errMsg msg } return json.Marshal(struct { Error *string json:Error *Alias }{Error: errMsg, Alias: (*Alias)(c)}) }ADR 特别说明了为什么这样做内嵌结构不动代码访问字段方式不变、JSON 输出结构完全一致向后兼容、显式列举全部字段配合维护者警告注释防止字段漂移、并且易于测试。需要修改的文件为server/events/command/project_result.go、server/events/command/result.go与result_test.go。5.4 Phase 2非 PR 工作流支持漂移检测的地基目标允许没有 PR 上下文的 API 操作为漂移检测铺路。实现分三步第一步在ProjectContext增加API字段注释明确说明由 API 端点触发的命令为 true当为 true 且Pull.Num 0时跳过 PR 专属需求approved、mergeable// server/events/command/project_context.go type ProjectContext struct { // ... existing fields ... // API is true if this command was triggered via API endpoint rather than PR comment. // When true and Pull.Num 0, PR-specific requirements (approved, mergeable) are skipped. API bool }第二步在命令上下文构建器project_command_context_builder.go中把ctx.API透传给ProjectContext。第三步在DefaultCommandRequirementHandler.validateCommandRequirement中跳过 PR 专属需求case raw.ApprovedRequirement: // Skip for API calls without PR - approval is PR-specific if ctx.API ctx.Pull.Num 0 { ctx.Log.Info(skipping approval requirement for API call without PR number) continue } case raw.MergeableRequirement: if ctx.API ctx.Pull.Num 0 { ctx.Log.Info(skipping mergeable requirement for API call without PR number) continue }设计要点ADR 明确强调的取舍approved与mergeable是 PR 专属检查PR 上下文之外没有意义非 PR 的 API 调用漂移检测、紧急 apply仍然要遵守其他需求例如undiverged带 PR 编号的 API 调用必须继续执行全部需求检查以维持 PR 工作流的安全性。依赖检查depends_on处理非 PR 的 API apply 必须在不依赖 VCS 事件的前提下处理项目间depends_on。ADR 要求在构建非 PR apply 的项目上下文前用合成synthetic的models.PullStatus播种ctx.PullStatus——每条记录使用项目配置中的ProjectName、RepoRelDir、Workspace状态初始为models.PlannedPlanStatus除非当前操作已知该项目无变更。由于APIController.apiApply目前用简单循环运行项目而非project_command_pool_executorAPI apply 路径必须在每个项目 apply 后立即更新ctx.PullStatus.Projects以Workspace、RepoRelDir、ProjectName匹配赋值为result.PlanStatus()使后续项目能看到依赖项目已是AppliedPlanStatus或PlannedNoChangesPlanStatus另一个备选方案是把非 PR API apply 也路由到 pool executor 统一管理状态更新。同时ValidateProjectDependencies必须在ctx.PullStatus为 nil 或声明的依赖缺失于合成状态时返回明确失败——非 PR API apply 请求要么在同一请求中包含全部依赖项目要么在 apply 前失败而不是 panic 或把依赖当作已满足。5.5 Phase 3漂移检测端点目标在 PR 工作流之外启用基础设施漂移检测。ADR 规划了两个能力增强/api/plan支持PR: 0或省略 PR 字段用于漂移检测。ADR 给出了可直接使用的 curl 示例curl -X POST https://atlantis/api/plan \ -H X-Atlantis-Token: secret \ -H Content-Type: application/json \ -d { Repository: org/repo, Ref: main, Type: Github, Paths: [{Directory: ., Workspace: default}] }新增GET /api/drift/status按仓库/项目查询已持久化的漂移状态。安全要求所有/api/drift/*端点必须在解析请求或返回数据前强制 API 认证——复用APIController.apiParseAndValidate中已有的X-Atlantis-Token校验或提取为共享的 API 认证辅助函数不能依赖 web basic auth因为/api/*路由的 handler 自己负责 API token 强制。请求的 API secret 未设置或 token 不匹配时直接拒绝。当前仓库源码 server/controllers/api_controller.go 中确实以const atlantisTokenHeader X-Atlantis-Token定义了该头并在APISecret []byte字段基础上构建APIMiddleware。响应增强ADR 强调漂移统计必须复用models.NewPlanSuccessStats或在 Terraform/OpenTofu 增加新计数器时扩展它而不是另写一套正则解析器以保证漂移 API 响应与 PR plan 评论、既有 summary 渲染保持一致。ADR 给出的解析函数骨架// server/events/models/drift.go func ParseDriftFromPlan(planOutput string) DriftSummary { stats : NewPlanSuccessStats(planOutput) return DriftSummary{ HasDrift: stats.Changes || stats.ChangesOutside, ToImport: stats.Import, ToAdd: stats.Add, ToChange: stats.Change, ToDestroy: stats.Destroy, ToForget: stats.Forget, ChangesOutside: stats.ChangesOutside, Summary: (PlanSuccess{TerraformOutput: planOutput}).Summary(), } }DriftSummary字段包括HasDrift、ToImport、ToAdd、ToChange、ToDestroy、ToForget、ChangesOutside与人类可读的Summary。存储与查询ADR 明确指出/api/drift/status是读取端点而非重新计算端点——每次成功的漂移检测/api/plan都必须用ParseDriftFromPlan解析每个项目的结果并持久化一条ProjectDrift记录记录包含 VCS 仓库身份type/hostname/repository 全名、请求源元数据Ref、项目身份ProjectName/Path/Workspace、解析出的漂移摘要与LastChecked查询端点按 VCS 仓库/ref/项目键过滤返回。ADR 还强调仓库键不应包含派生的RepoID仅在需要日志或下游 API 调用时从同一组 hostname/repository 字段推导models.Repo.ID()如果实现选择按需计算漂移则查询端点请求形态必须改为包含Ref、VCS type、hostname、repository 与Paths并同步执行 plan。存储接口草案如下// server/core/drift/storage.go type DriftStorage interface { StoreDriftStatus(repo models.DriftRepositoryKey, status models.ProjectDrift) error GetDriftStatus(repo models.DriftRepositoryKey, key models.DriftProjectKey) (*models.ProjectDrift, error) ListDriftStatus(repo models.DriftRepositoryKey, ref string) ([]models.ProjectDrift, error) } // 初始版本的内存实现 type InMemoryDriftStorage struct { mu sync.RWMutex status map[models.DriftRepositoryKey]map[models.DriftProjectKey]models.ProjectDrift }5.6 Phase 4漂移修复自动创建 PR/MR目标通过自动创建 PR/MR 聚合漂移修复打通检测 → 修复 → 评审 → 合并闭环。前提VCS Client 接口必须支持 PR/MR 创建——ADR 指出当时 PR 创建只存在于 E2E 测试代码中。ADR 为vcs.Client接口规划了两个新方法及选项类型// server/events/vcs/client.go type Client interface { // ... existing methods ... CreatePullRequest(logger logging.SimpleLogging, repo models.Repo, opts CreatePullRequestOptions) (models.PullRequest, error) CreateBranch(logger logging.SimpleLogging, repo models.Repo, branchName string, fromRef string) error } type CreatePullRequestOptions struct { Title string Body string HeadBranch string // 源分支例如 drift-remediation-2025-01-21 BaseBranch string // 目标分支例如 main Draft bool Labels []string Assignees []string }GitHub 实现通过PullRequests.Create创建 PR、通过Git.GetRefGit.CreateRef从源 ref 创建分支GitLab 实现通过MergeRequests.CreateMergeRequest创建 MR并将 Draft 前缀化为Draft: titleGitLab 用标题前缀标识草稿 MR。修复端点POST /api/drift/remediate的请求体包含Repository、Ref基分支、TypeVCS 类型、可选的Projects/Paths筛选、Title、Description、Draft与AutoMerge响应返回PullRequestInfoNumber/URL/Branch/Title。修复 handler 必须在创建分支、提交或 PR/MR 前强制共享 API-token 认证未认证请求必须在跑 plan 或暴露漂移数据之前被拒绝。修复工作流5 步对每个指定项目跑 plan探测需要 apply 的内容创建新分支如atlantis-drift-remediation-{timestamp}先在分支上落地一个非空变更materialize a non-empty branch change——可以是生成的漂移修复 manifest/报告、修复引擎提出的配置编辑或其他可评审产物如果 Atlantis 无法创建使 head 与 base 产生差异的提交则返回带漂移摘要的错误而非调用CreatePullRequest创建 PR/MR在描述中附带漂移摘要返回 PR 详情交用户评审合并。5.7 Phase 5附加 API 增强ADR 规划的运维类端点与鉴权要求端点方法鉴权描述GET /api/projectsGET是列出已配置项目GET /api/runsGET是列出最近的 plan/apply 运行DELETE /api/locks?id{lockID}DELETE是强制解锁指定锁其中DELETE /api/locks有一个容易踩坑的实现细节Atlantis 锁键格式为repo/path/workspace/project天然包含斜杠不能作为单一 URL 路径段建模。因此强制解锁端点必须使用查询参数、请求体字段或显式 catch-all 路由完整保留 URL 转义后的值再调用Locker.Unlock(lockID)——锁 ID 取自GET /api/locks返回的LockDetail.Name。5.8 实施计划与风险表ADR 为每个阶段给出了排期与任务清单ChecklistStage 1 错误序列化1-2 周为ProjectResult/Result添加MarshalJSON、补单元测试与集成测试验证 API 响应格式不变、加维护者警告注释Stage 2 非 PR 支持1-2 周加API字段、透传 flag、改造需求 handler、补全 API/非 API × 有无 PR 的全组合单测与漂移检测集成测试Stage 3 漂移检测2-3 周创建复用NewPlanSuccessStats的响应模型、实现内存存储、持久化解析结果、加/api/drift/status端点与文档Stage 4 漂移修复3-4 周扩展 VCS Client 接口、更新ClientProxy与NotConfiguredVCSClient、逐 VCS 实现或显式返回 unsupported 错误、定义并测试分支落地至少一个提交的步骤、加/api/drift/remediate端点Stage 5 附加功能1-2 周加/api/projects、/api/runs、DELETE /api/locks更新 API 文档并考虑未来 API 版本化。ADR 的风险与缓解表风险缓解MarshalJSON中字段不同步维护者警告注释 linter 检查VCS 提供方差异通过接口抽象 全面测试安全非 PR apply保留其他需求检查 审计日志API 稳定性未来考虑版本化保持兼容6. 从 Proposed 到落地当前仓库源码中的实现证据ADR 0002 状态虽为 Proposed但从当前仓库源码看其核心能力已经成体系地落地。这为读者提供了一份ADR 如何转化为真实代码的绝佳对照样本。6.1 路由已注册漂移与修复端点全部上线server/server.go 中已注册的 API 路由s.Router.HandleFunc(/api/apply, s.APIController.Apply).Methods(POST) s.Router.HandleFunc(/api/locks, s.APIController.ListLocks).Methods(GET) s.Router.HandleFunc(/api/drift/status, s.APIController.DriftStatus).Methods(GET) s.Router.HandleFunc(/api/drift/detect, s.APIController.DetectDrift).Methods(POST) s.Router.HandleFunc(/api/drift/remediate/{id}, s.APIController.GetRemediationResult).Methods(GET) s.Router.HandleFunc(/api/drift/remediate, s.APIController.ListRemediationResults).Methods(GET) s.Router.HandleFunc(/api/drift/remediate, s.APIController.Remediate).Methods(POST)对照 server/server_test.go 中的路由断言GET /api/locks、GET /api/drift/status、POST /api/drift/detect、GET/POST /api/drift/remediate均有测试覆盖。6.2 控制器能力注入server/controllers/api_controller.go 的APIController已包含 ADR 规划的关键依赖APISecret []byteatlantisTokenHeader X-Atlantis-Token常量 懒加载的APIMiddlewaresync.Once初始化DriftStorage drift.Storage与RemediationService drift.RemediationServiceEnableDriftRemediation bool开关非 PR 工作流相关设施可选的PullReqStatusFetcherPR 编号存在时填充PullRequestStatus让mergeable/approved等 apply 需求基于真实 VCS 状态评估而非恒失败、PullStatusFetcher、LivePullHeadFetchercleanupNonPRWorkingDir当ctx.Pull.Num 0时清理非 PR API 工作目录——从源码结构看非 PR 的 API 请求通过nextNonPRPullNum()生成负数 Pull 编号-int((time.Now().UnixNano() 0x3fffffff) nonPRPullCounter.Add(1))来区分driftFullDetectionLocks sync.Map按(Repository, Type, Ref, BaseBranch)维度对全量漂移检测加互斥锁防止同一仓库并发全量检测。APIRequest结构体包含Repository、Ref、BaseBranch、Type、PR、Projects、PathsProjectName/Directory/Workspace以及内部使用的DiscoverProjects字段并带validate:required标签与 ADR 中的请求形态一致。6.3 漂移数据模型已实现且比 ADR 更完整server/events/models/drift.go 将 ADR 草案全部落地并做了增强DriftSummaryHasDrift、ToAdd、ToChange、ToDestroy、ToImportTerraform 1.5、ToForget、Summary、ChangesOutside并附带TotalChanges()聚合方法ProjectDrift在 ADR 基础上增加了BaseBranch、ResolvedCommit修复时避免对移动中的 ref 应用过期漂移、DetectionID、PlanOutputjson:-瞬态存储层会剥离与Error字段DriftStatusResponseRepository、Projects、CheckedAt并增加TotalProjects与ProjectsWithDrift统计DriftDetectionRequest/DriftDetectionResult对应POST /api/drift/detect支持BaseBranch、IncludePlanOutputValidate()方法逐项校验 repository/ref/base_branch/type/projects/paths解析辅助NewDriftSummaryFromPlanStats(stats, summary)与NewDriftSummaryFromPlanSuccess(plan)二者都复用PlanSuccessStats——与 ADR复用而非另写解析器的要求完全一致安全辅助函数从源码结构看是落地过程中新增的防御层IsSupportedDriftVCSHostType当前支持 Github/Gitlab/Gitea、IsValidAPIRepositoryForType、IsUnsafeAPIRef拦截pull/merge-requests命名空间与以-/开头的危险 ref、NormalizeAPIRef、CheckedBaseBranchRef、NormalizeAPIPath、IsValidAPIWorkspace等防止调用方通过 ref/path 注入攻击 git fetch 行为。6.4 漂移存储实现server/core/drift/storage.go 落地了 ADR 的存储要求接口在草案基础上演进为面向仓库的操作type Storage interface { Store(repository string, drift models.ProjectDrift) error Get(repository string, opts GetOptions) ([]models.ProjectDrift, error) Delete(repository string, projectName string) error DeleteMatching(repository string, opts GetOptions) error GetAll() (map[string][]models.ProjectDrift, error) }GetOptions支持按ProjectName/Path/Workspace/Ref/BaseBranch精确过滤、MaxAge时效过滤与Exact模式。InMemoryStorage的键由ProjectName Path Workspace Ref BaseBranch组成——Ref 参与键设计确保同一项目在不同分支上的漂移记录互不覆盖这正是 ADR 反复强调的存储语义。同时Store在持久化前强制drift.PlanOutput 剥离瞬态 plan 文本与ProjectDrift.PlanOutput的json:-标注和接口注释形成完整闭环。从源码结构看存储实现目前为内存版服务重启即丢失接口注释也保留了未来接入数据库或外部服务的扩展点//go:generate已配置生成 mock。6.5 测试覆盖server/controllers/api_controller_test.go 为漂移检测与修复提供了大量测试用例覆盖范围包括正确的X-Atlantis-Token请求、错误 token 的 401 拒绝、缺失 token 的拒绝、Projects/Paths二选一校验、非法目录穿越如env../../tmp/plan的拒绝、不支持的 VCS typeGitlab/Gitea 边界、ref与base_branch组合校验、依赖项目缺失的失败、include_plan_output开关、按 id 查询/列出修复结果、limit 参数等。这些测试证明了 ADR 中API-token 强制 输入校验 依赖检查的安全设计已经全面落地。7. 对贡献者的实操建议综合 docs/adr/README.md 的流程规定与 ADR 0002 的实践样本给参与 Atlantis 开发的读者三点建议小改动走 PR大决策先写 ADRBug 修复、文档、测试直接开 PR凡是触碰 API 契约、持久化、并发/锁、认证授权或不可逆变更的先开 issue 对齐问题再按 模板 提交Proposed状态的 ADR接受后才动手实现维护 ADR 与代码的双向索引被接受的 ADR 要在实现 PR 中链接新增或变更 ADR 时要同步更新 README 索引表被取代的决策用新 ADRSuperseded by NNNN覆盖不要改写历史以 ADR 0002 为范本学习设计先行它在动工前就锁定了响应结构不变、复用NewPlanSuccessStats、ref 参与存储键、API token 强制、非 PR 保留非 PR 专属需求之外的检查等约束随后的源码实现几乎逐条兑现。这正是 ADR 的核心价值——把决策的上下文、取舍与约束留给未来的维护者让为什么与怎么做永远可见、可追溯。赞分享DevOpsCI/CD基础设施【免费下载链接】atlantisTerraform Pull Request Automation项目地址https://gitcode.com/gh_mirrors/at/atlantis点击查看免费下载相关推荐Atlantis API 增强与漂移检测Drift Detection架构决策实践指南Atlantis API 增强与漂移检测Drift Detection架构决策实践指南 导读 本文深入解析 Atlantis 仓库中的架构决策记录 000DevOpsCI/CD基础设施使用 ADR 模板记录架构决策Atlantis 项目的架构决策记录实践指南使用 ADR 模板记录架构决策Atlantis 项目的架构决策记录实践指南 导读 本文围绕 Atlantis 仓库中的 docs/adr/template.mDevOpsCI/CD基础设施plannotator 架构决策记录ADR实践指南从 ADR-0001 到 007 的决策治理体系plannotator 架构决策记录ADR实践指南从 ADR 0001 到 007 的决策治理体系 导读 本文围绕 plannotator 仓库中的 AD上一篇SleeperX重新定义MacBook智能睡眠管理的完整解决方案下一篇SleeperX让MacBook告别不合时宜的休眠困扰创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考