상세정보

IDG 블로그 | 테스트 자동화 없이는 클라우드 데브옵스도 없다
저녁 8시 새로운 클라우드 네이티브 애플리케이션을 만들기 위한 스트린트를 완료하고자 한다. 데드라인은 정했다. 하지만 애플리케이션을 테스트 그룹에 보내는 데는 2주가 더 걸리고, 그 이후에 배치를 하고 운영팀에 넘겨야 한다. 아이디어에서 운영팀에 넘겨지는 데까지 걸린 시간을 고려하면 애자일 개발이 그다지 민첩하지 않은 것 같다.

뭐가 잘못됐을까? 오늘날의 문제는 클라우드 네이티브 애플리케이션의 테스트와 배치를 위한 자동화가 충분하지 않다는 것이다. 그래서 이 까다로운 사람들이 테스트 과정에서 개입해야만 하고, 이 때문에 작업은 더뎌지고 오류도 더 많아질 가능성이 크다. 게다가 클라우드 네티이브 애플리케이션의 테스트는 어떠해야 하는지 제대로 이해하고 있는 테스터도 충분하지 않아서 테스트를 위해 접근법이나 메커니즘을 파악하는 데도 시간이 지체된다.

클라우드 네이티브 암호화나 ID 및 액세스 관리 시스템을 사용해 애플리케이션의 안정성을 판단하는 역량을 예로 들 수 있다. 아니면 클라우드 네이티브 자동 확장 서비스를 사용해 6대의 서버 인스턴스를 확장하는 것이 충분한 규모인지를 파악하는 역량도 필요하다. 이들 역량은 특정 클라우드 서비스 업체에 특화된 것이다.

많은 전문가가 클라우드 네이티브 애플리케이션을 이렇게 테스트하라고 한다. 이를 통해 클라우드 네이티브란 무엇이고 어떤 것인지, 베스트 프랙티스는 무엇인지, 좋은 클라우드 네이티브 애플리케이션과 그렇지 않은 애플리케이션은 무엇인지 등에 대해 더 많은 것을 알 수 있다는 것.

하지만 필자의 조언은 이런 모든 것을 한꺼번에 없애 버리라는 것이다. 대신 책임을 클라우드 네이티브 애플리케이션 개발자에게 다시 맡겨 테스트를 자동화하는 스크립트를 포함한 테스트 계획까지 수행하도록 한다. 물론 플랫폼을 어떻게 설정하고 애플리케이션이 어디서 실행되는지를 클라우드 서비스 업체에 알려주는 IAC(infrastructure as code)도 맡겨야 한다.... 더보기

IDG 블로그 | 테스트 자동화 없이는 클라우드 데브옵스도 없다 www.itworld.co.kr 저녁 8시 새로운 클라우드 네이티브 애플리케이션을 만들기 위한 스트린트를 완료하고자 한다. 데드라인은 정했다. 하지만 애플리케이션을 테스트 그룹에 보내는 데는 2주가 더 걸리고, 그 이후에 배치를 하고 운영팀에 넘겨야 한다. 아이디어에서 운영팀에 넘겨지는 데까지 걸린 시간을 고려하면 애자일 개발이 그다지 민첩하지 않은 것 같다.뭐가 잘못됐을까? 오늘날의 문제는 클라우드 네이티브 애플리케이션의 테스트와 배치를 위한 자동화가 충분하지 않다는