Rails 어플리케이션을 수십 줄 Ruby로 교체하는 방법

몇 년 전에 나는 업무 중에 계기판을 망가뜨렸다.
새로운 특성을 구축하는 일부분으로 데이터베이스 모델을 변경했습니다.나는 새로운 열을 추가하고 기존 데이터를 이전할 계획을 꼼꼼히 세웠다.나는 데이터베이스에 대한 변경이 새롭고 낡은 응용 프로그램 코드와 함께 사용할 수 있을 뿐만 아니라, 이 기능을 정지하지 않고 배치할 수 있을 것이라고 확신한다.
나는 우리의 응용 프로그램이 우리 데이터의 유일한 소비자가 아니라는 것을 잊어버렸다.우리의 데이터 팀은 계기판을 유지하고 있으며, 이 회사는 제품의 결정을 통지하고 재무 예측을 하는 데 쓰인다.이 계기판들은 우리의 데이터베이스 모델이 일정한 방식으로 보이기를 기대한다. 내가 데이터 팀과 이야기를 나누지 않은 상황에서 변경을 진행할 때 그 중의 한 계기판이 고장났다.
우리가 계기판을 고친 후에, 나는 어떻게 자신이 장래에 같은 실수를 범하는 것을 방지할 것인가를 생각했다.나는 데이터베이스 모드를 변경할 때마다 알림이 필요하다고 결정했다.알림을 받기 위해 가장 익숙한 도구를 찾았고 새로운 Rails 응용 프로그램을 개발했습니다.

Rails 어플리케이션은 여러 가지 장점이 있습니다.

내 응용 프로그램 DiffAlert의 목표는 누군가가 우리 회사 응용 프로그램의 db/structure.sql 지점에서 master으로 변경할 때마다 Slack에 경보를 보내는 것이다.GitHub에 webhookspush event이 제출된 데이터를 보냈습니다. 어떤 파일이 변경되었는지 포함합니다.
몇 시간 후, 나는 GitHub 웹 훅 이벤트를 위한 노드를 만들고 db/structure.sql이 주어진 전송에서 변경되었는지 판단하기 위해 코드를 작성했다.DiffAlert의 핵심 논리가 완료되었습니다.그리고 진정한 일이 시작되었다.
다음은 Slack에 경보를 보내는 방법을 찾아야 합니다.우리는 이미 Slack’s Email app을 사용하고 있기 때문에 나는 새로운 Mailgun 계정을 등록했고 Action Mailer으로 전자 우편 템플릿을 만들었다.그리고 나는 어딘가에 DiffAlert를 배치해야만 했다. 그래서 나는 새로운 Heroku 응용 프로그램을 만들었고 모든 내용이 나의 업무 흐름을 정확하게 설정할 수 있도록 조정했다.db/structure.sql 외에도 코드 라이브러리에 있는 다른 파일들을 감시하고 싶어서 경보 설정을 설정하기 위해 UI를 구축하기 시작했습니다.나는 신분 검증이 필요하기 때문에 데이터 모델을 설계하고 로그인과 등록 폼을 만들었다.그리고 모든 경보를 표시하기 위해 다른 보기가 필요합니다. 새 경보를 만들고 기존 경보를 편집하는 표가 필요합니다.웹 훅 해석과 전자 우편 발송 같은 더 긴 과정이 필요하기 때문에 일반적인 웹 요청을 막지 않습니다.

DiffAlert는 약 1년 반 동안 지속되어 우리 팀에게 데이터베이스 모드를 변경할 때 아무 일도 하지 말라고 일깨워 주었다.매번 우리는 데이터 팀에 연락하여 더 이상 어떤 계기판도 파괴하지 않는다.
DiffAlert는 부대 프로젝트이기 때문에 제가 회사를 떠날 때 직원들에게 GitHub 메타데이터를 계속 보내고 자신의 DiffAlert 실례를 유지할지 경보 수신을 정지할지 결정해야 합니다.그들은 경보 수신을 중지하기로 결정한 것은 이해할 수 있다.

GitHub의 행동은 제가 이 문제에 집중할 수 있도록 도와줍니다.

GitHub에서 일하고 있습니다. GitHub Actions을 알게 되었을 때, DiffAlert 대신 동작을 사용할 수 있는지 알고 싶습니다.GitHub 작업은 저장소에서 지정된 이벤트가 발생하면 Docker 컨테이너에서 실행되는 모든 언어로 작성된 코드입니다.GitHub 작업 흐름을 트리거할 수 있는 push events을 보았습니다.나는 또한 a GitHub Action이 Slack에 소식을 발표할 수 있는 것을 보았다.나는 Modified File Filter을 쓰기 시작했다.
우선, Dockerfile이 필요합니다.나는 루비로 나의 조작을 작성하고 싶어서 FROM 명령을 사용하여 an official Ruby base image에서 Docker 용기를 만들었다.GitHub 작업 시각화 워크플로우 편집기에 내 작업이 제대로 표시되도록 some LABEL instructions을 작성했습니다.마지막으로 Docker 컨테이너에 액세스할 폴더를 지정하고 ENTRYPOINT을 실행 가능한 루비 스크립트로 지정했습니다.

# Dockerfile

FROM ruby:2.6.0

LABEL "com.github.actions.name"="Modified File Filter"
LABEL "com.github.actions.description"="Stops a workflow unless a specified file has been modified."
LABEL "com.github.actions.icon"="filter"
LABEL "com.github.actions.color"="orange"

ADD bin /bin
ADD lib /lib

ENTRYPOINT ["entrypoint"]

실행 가능한 루비 스크립트는 대부분의 작업을 일반적인 오래된 루비 클래스 PushEvent에 의뢰합니다. 이 클래스는 GitHub의 이벤트 데이터를 분석하고 특정 경로의 파일을 수정했는지 대답합니다.이벤트 수정 파일을 푸시할 때 작업이 종료되고 상태는 0으로 워크플로우의 다음 작업을 촉발합니다.푸시 이벤트가 파일을 수정하지 않으면 작업이 1을 종료하여 워크플로우를 중지합니다.

# bin/entrypoint

require_relative "../lib/push_event"

file_path = ARGV.first
push_event = PushEvent.new(File.read(ENV.fetch("GITHUB_EVENT_PATH")))

if push_event.modified?(file_path)
  puts "#{file_path} was modified"
  exit(0)
else
  puts "#{file_path} was not modified"
  exit(1)
end

기존의 GitHub 작업으로 Slack을 구현할 수 있기 때문에 이메일을 설정하거나 Slack과 통합하는 방법을 알 필요가 없습니다.GitHub에서 처리하기 때문에 UI나 인증을 설계할 필요가 없습니다.데이터베이스나 백그라운드 작업을 설정할 필요가 없습니다.Heroku 응용 프로그램을 시작하고 배포를 설정할 필요가 없습니다.

시작 시 작음

Rails는 아이디어를 검증하는 훌륭한 프레임워크로 유명합니다.Rails를 사용할 수 있습니다!저는 Rails를 즐겨 사용하기 때문에 항상 생각이 있을 때 먼저 합니다.
그러나 Rails가 모든 마력을 제공한다고 해도 대부분의 응용 프로그램은 인증, 사용자 인터페이스, 백엔드 작업, 이메일 발송, 배치 등 많은 것을 필요로 한다. 이것은 나의 유일한 생각이 아니다.다음에 생각이 하나 생겼어요. 코드를 더 적게 쓰고 인프라 시설을 최소한 처음부터 유지할 수 있는 방법을 생각해 볼게요.
표지 사진은 은 팔레르가 Flickr에서 촬영했다.