오늘해야할일들
-
socket.io 양방향 통신 [완료]
-
socket.io 메시지 통신 [완료]
-
socket.io 퇴장하기 기능 [완료]
-
CI CD 구축하기 [실패]
-
Jenkins 완성해보기 [실패]
-
챌린지 api 수정 및 보완하기
-
도커 강의 듣기 [완료 2개 듣고 배포까지 완료]
-
CI CD
CI/CD의 “CI” 는 개발자를 위한 자동화 프로세스인 지속적인 통합(Countinuous Integration)을 의미한다.
“CI” 를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로, 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.
“CD” 는 지속적인 서비스 제공(Countinuous Delivery) 및/또는 지속적인 배포(Countinuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.
두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.
지속적인 제공(Countinuous Delivery)
개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예:GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것을 뜻하며, 운영팀은 이 리포지토리에서 애필리케이션을 실시간 프로덕션 환경으로 배포할 수 있다.
이는 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결해 준다.
지속적인 제공은 귀찮은 push 작업없이 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 한다.
지속적인 배포(Countinuous Delivery)
개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 것을 의미한다.
이는 애플리케이션 제공 속도를 저해하는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결한다.
지속적인 배포는 파이프라인의 다음 단계를 자동화함으로써 지속적인 제공이 가진 장점을 활용한다.
CI/CD 장점
CI / CD를 실천하면 개발, 테스트, 운영 모범 사례에 팀을 맞춤으로써 다음과 같은 실질적 혜택도 얻을 수 있다.
-
변경 사항을 자주 푸시하고자 하는 개발자와 안정적인 애플리케이션을 원하는 운영 담당자 사이의 마찰을 해결한다.
-
코드 변경을 사용자에게 푸시하기 전에 검증하기 위해 개발 팀은 지속적인 테스트를 실행해야 한다.
-
큰 변경보다 안정적으로 통합 및 테스트가 가능한 더 작은 큐모의 증분적 코드 변경을 수행하도록 개발자를 독려한다.
-
새로운 기능을 위한 더 넓은 범위의 개발 작업을 수행하는 동시에 신속한 수정 요청까지 받는 팀에 작업의 유연성을 부여한다.
-
기능, 성능 및 데이터 중심 테스트를 더 많이 실행해서 더 높은 품질의 애플이케이션을 제공하고 프로덕션 결함을 줄일수 있게 해준다.
CI/CD Pipeline : 파이프라인이라고 하는 이유는 이러한 배포 자동화 과정들이 물 흐르듯 흘러가는 것을 묘사해서 그렇게 부르게 돤다.
-
챌린지 api 수정 및 보완
const detailJoin = async(req,res) => {
if (!res.locals.user) {
res.status(401).json({
result:false,msg:"로그인 후 사용하세요",
})
return
}
const {userId,challengeNum} = req.query //로그인하고있는 유저
const {challengeCnt} = req.body
try {
//!! 추후 findOne -> findAll로 수정해야함 !!
//동시성 이슈가 있을수도있다? => a라는 유저,b라는 유저가 72번 챌린지참여를 한번에했을때
//DB에 중복해서 쌓일수도있다.
const existUsers = await ChallengeJoin.findOne({where :{
userId:userId,
[Op.and]:[{userId},{challengeNum}]
}})
// console.log(existUsers)
if (existUsers) {
res.status(400).json({result:false,msg:"이미 참여하고있는 챌린지입니다."})
}else if (!existUsers) {
const steps = await Challenge.findOne({attributes:['steps'],where:{challengeNum:challengeNum}})
await Challenge.increment({challengeCnt:1}, {where:{challengeNum}})
const challengejoin = await ChallengeJoin.create({userId,challengeNum,steps:steps.dataValues.steps})
res.status(201).json({result:true,msg:"챌린지리스트 성공",challengejoin})
}
else {
res.status(400).json({result:false,msg:"이미 참여하고있는 챌린지입니다."})
}
}catch(error) {
console.log(error,'챌린지리스트 오류')
res.status(400).json({result:false,msg:"챌린지리스트 실패"})
}
};챌린지가 개설되었고 개설된 챌린지에 참여할수있다 하지만 동일한 유저가 중복으로 참여하면 안돼기 때문에 조건을 걸었다
const existUser = await ChallengeJoin.findOne(
//ChallengeJoin 테이블에서 userId를 통해서 Read하고
{where : {userId:userId},
//프론트에서 전달해준 userId와 challengeNum과 동일한 데이터를 찾는다는 코드이다.
[Op.and]:[{userId},{challengeNum}]
})태균님 말씀으로는 원래 findAll을 사용해야한다고했다 왜냐하면 findOne은 하나만 찾는다는내용이고 findAll은 전체를 조회한다는 내용인데 전체를 비교해야 정확성이 높아지기때문이다.
하지만 코드를 잘못짜서 그런지 findAll 메서드를 사용하였을때 오류가 발생한다…
그래서 일단은 findOne을 사용하였고 해당 내용을 기술매니저님께 문의하였을때에 findOne로 사용해도 괜찮을거같다는 답변을 받았다 추후에 해당부분은 수정할수있다면 수정하려고한다.
- 소켓 적용 프론트 create-react-app 즉 CRA를 생성하였고 프론트의 코드를 작성하고 서버쪽 코드도 작성하였다. 유튜브를 통해서 구현하였고 성영님께 해당코드를 전달드렸을때에 이상없이 잘 작동하였다.
