<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Jira on 얼쑤 · Team Edo</title><link>https://team-edo.github.io/tags/jira/</link><description>Recent content in Jira on 얼쑤 · Team Edo</description><generator>Hugo</generator><language>ko-kr</language><lastBuildDate>Wed, 28 Oct 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://team-edo.github.io/tags/jira/index.xml" rel="self" type="application/rss+xml"/><item><title>Jira 작업 생성 뒤 다시 읽는 이유</title><link>https://team-edo.github.io/posts/2026/10/verify-jira-task-after-create/</link><pubDate>Wed, 28 Oct 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/10/verify-jira-task-after-create/</guid><description>&lt;p>개발 작업을 시작할 때 Jira에 작업을 만들고 담당자와 스프린트를 지정했습니다. 생성할 때 필드를 한꺼번에 보내면 요청 한 번으로 끝날 거라고 생각했습니다. 당시 사용한 연결 도구에서는 스프린트 값을 포함한 생성 요청이 &lt;strong>HTTP 400&lt;/strong>으로 거절됐습니다. 값을 빼고 작업을 만들자 요청은 성공했지만, 응답에 적힌 담당자는 요청에 넣은 사람과 달랐습니다. 요청을 받아들였는지와 기대한 값이 남았는지를 따로 확인해야 했습니다.&lt;/p>
&lt;h2 id="생성과-배정을-분리했다">생성과 배정을 나눠 재조회&lt;/h2>
&lt;p>먼저 스프린트 값을 빼고 작업을 만들었습니다. 생성 응답에서 실제 작업을 가리키는 키를 얻은 뒤, 그 작업에 상태 전환과 스프린트 배정을 요청했습니다. 생성 응답에서 다르게 표시된 담당자도 확인해 수정했습니다. 담당자가 바뀐 이유로 프로젝트 기본값을 의심했지만, 어느 설정이 적용됐는지까지는 확인하지 못했습니다.&lt;/p></description></item><item><title>MR 병합 뒤에도 운영 확인이 남았다</title><link>https://team-edo.github.io/posts/2026/10/mr-merge-and-operational-verification/</link><pubDate>Wed, 28 Oct 2026 00:00:00 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/10/mr-merge-and-operational-verification/</guid><description>&lt;p>새 약관 API를 운영에서 호출해 HTTP 200을 받는 것이 한 작업의 완료 조건이었습니다. MR이 병합되자 Jira는 작업을 완료로 표시했지만, 같은 시점에 운영 API는 &lt;strong>404&lt;/strong>를 반환했습니다.&lt;/p>
&lt;h2 id="자동-종료가-가리키는-작업을-확인했다">자동 종료 대상과 운영 응답 확인&lt;/h2>
&lt;p>저희 프로젝트는 MR이 병합되면 연결된 작업을 완료로 전환했습니다. 약관 사례에서는 배포 이력과 운영 응답을 계속 확인해 새 버전의 &lt;strong>200&lt;/strong> 응답까지 기록했습니다. 배포가 막힌 원인과 복구 과정은 별도 글에 정리했습니다. &lt;a href="https://team-edo.github.io/posts/2026/10/separate-deployment-health-probes/">인증 추가 뒤 자동 배포가 10번 실패한 이유&lt;/a>&lt;/p></description></item><item><title>0.2.0 팀 규칙은 어디에 둘까</title><link>https://team-edo.github.io/posts/2026/10/coco-0-2-0/</link><pubDate>Tue, 20 Oct 2026 10:32:34 +0900</pubDate><guid>https://team-edo.github.io/posts/2026/10/coco-0-2-0/</guid><description>&lt;p>얼쑤에서 AI에 푸시를 맡기려면 먼저 무엇을 확인해야 할지 정해야 했습니다. 개발 브랜치가 바뀌었는지, 기존 테스트 결과를 재사용해도 되는지, Jira에는 언제 무엇을 남겨야 하는지가 모두 판단 대상이었습니다. HTTPS 전환 작업에서는 최신 개발 브랜치가 이미 작업 브랜치에 포함돼 검사 19개의 결과를 재사용했습니다. 서버 점검 작업에서는 새 변경을 통합한 뒤 테스트 13개를 다시 실행했습니다. 두 사례를 놓고 보면 팀별 기록 규칙과 검증을 다시 할 조건을 각각 어디에 둘지가 문제였습니다.&lt;/p></description></item></channel></rss>