#side_project #elixirlang slab 후기 - gitlab API를 사용해 귀찮은 일을 덜어주는 slack 봇
url을 입력하면 프리뷰를 url 밑에 붙여주는 unfurling links 기능이 필요했다. gitlab을 내부망에 설치해 사용하고 있다. 내부망에 접근할 방법이 없어 slack이 기본으로 제공하는 gitlab 이슈 프리뷰가 안 나온다. slack과 gitlab에 접근할 수 있는 머신에서 실행하는 slab이 gitlab 이슈를 수동으로 풀어준다.
하다보니 기능이 막 붙는다. gitlab 이슈를 조회하는 기능. merge request 없이 푸시한 커밋을 조회하는 기능. self merge를 조회하는 기능. 브랜치 접근 레벨을 변경하는 기능. 파이프라인 상태를 조회하는 기능. 파이프라인 상태를 감시해 깨지거나 고쳐지면 slack 채널에 통보하는 기능. 자잘하지만 있으면 편한 기능이 대부분이다.
merge request 없이 푸시한 커밋을 조회하는 기능과 self merge를 조회하는 기능은 프로그램팀 문화와 관련있다. 아트팀도 gitlab을 쓰고 있어서 master 브랜치에 커밋을 푸시하는 기능을 막지 않았다. merge request는 리뷰어가 머지(merge)하는 게 원칙이지만 스스로 머지하는 걸 막지 않았다. 여기서 규칙 문제가 생긴다. 어떤 건 self merge해도 되고 어떤 건 merge request 없이 푸시해도 되는가. 지키지 못할 복잡한 규칙을 만드는데, 힘을 쓰고 싶지 않다. 간단한 규칙을 만들었다. slab이 slack 채널에 통보한다. 팀 동료에게 설명할 수 있는 정당한 사유가 있다면 merge request 없이 푸시하건 self merge를 하건 상관없다.
브랜치 접근 레벨을 변경하는 건 매주 진행하는 팀 테스트 때문에 만들었다. 전원이 참석하다 보니 master 브랜치 접근 권한을 잠시만 막는다. 이걸 gitlab 웹페이지로 하려면 메뉴를 여러 번 타고 들어가야 한다. 매주 해야 하는데, 귀찮아서 slab에 기능을 추가했다. 공지 채널에 명령어를 입력하면 설명과 동작이 한 번에 돼서 편하다. 머지 막습니다. 이런 공지를 따로 할 필요가 없기 때문이다.
파이프라인 상태를 감시하고 조회하는 기능은 기대한 만큼 메일 확인을 안 해서 만들었다. gitlab은 파이프라인이 실패하면 머지한 사람에게 메일을 보낸다. 머지한 사람이 확인해서 저자에게 고치라고 알려주면 되는데, 이게 잘 안 되더라. 그래서 속 편하게 slack 채널에 통보하게 했다. 효과는 좋다. 빠르게 반응하지는 않는다. 하지만 적어도 내가 원인을 파악하고 문제를 일으킨 사람을 찾는 작업이 아주 간편해졌다. 난 이걸로 충분히 더 편해졌다.
언어는 당연히 elixir. 업무로 사용하는 언어라서 고민 없이 선택했다. 언어 숙련도를 높이고 내가 편해지는 사이드 프로젝트도 만들고. 꿩먹고알먹고 되겠다.
changelog를 썼다. 종류별로 목록이 한눈에 들어와서 변경 사항 파악이 쉽다. 사이드 프로젝트에 뭘 이런 걸 다. 이런 생각도 들었지만 연습하는데 사이드 프로젝트만 한 게 없다는 생각이 들어 썼다. tag를 만들고 release도 만들었다. changelog를 쓰니 릴리즈 노트 쓰는 게 간편하다. 복사 붙여넣기만 하면 된다.
커밋 메시지 규칙과 작업 일지 같은 개발 환경은 이전 사이드 프로젝트인 tpass와 비슷했다. 만드는 데 40시간이 걸렸다. 기능이 추가되면서 시간이 계속 늘어났다. 데드라인 없이 개발해서 마감을 딱히 정하진 않았다. 지루해지기 전에 끝낸다 정도만 지키고 싶었다.
다음 사이드 프로젝트도 slack 봇이다. 원래 만들려고 했던 봇이다. slab은 gitlab api, slack api를 써서 몸풀기로 만든 봇이다.
프로젝트 홈페이지 - ohyecloudy/slab - github.com
