Как мы строим внутренний контроль качества в компании по тестированию
newsare.net
В нашей компании по тестированию ПО на аутсорсе мы постоянно сталкиваемся с тем, что формат сотрудничества диктует инфраструктура заказчика
Как мы строим внутренний контроль качества в компании по тестированию
В нашей компании по тестированию ПО на аутсорсе мы постоянно сталкиваемся с тем, что формат сотрудничества диктует инфраструктура заказчика. На одном проекте нас ждет построенная по всем канонам CI/CD, а на другом полное отсутствие VCS. В таких условиях легко потерять контроль над качеством нашей работы. В этой статье я расскажу, как мы выстроили внутренний контур качества, используя собственную инфраструктурную прослойку, и почему от этого решения в итоге хорошо и нам, и заказчику. Когда мы заходим на проект, то почти всегда встраиваемся в существующую экосистему.Однако, при таком варианте мы теряем возможность управлять результатом нашей работы. Работая исключительно на стороне клиента, мы не можем внедрить обязательное внутреннее ревью кода, настроить свои стандарты CI/CD-пайплайнов или, например, использовать привычные нам инструменты отчетности.Бывает ситуации и сложнее. Например, у клиента есть CI/CD, но из-за требований безопасности им нельзя подключать внешние раннеры. Бывает случаи, когда у клиента нет своего CI/CD. Поднять его у себя они не могут (нет на это ресурсов, людей или того и другого), а использовать публичные или даже приватные облака запрещает какое-нибудь внутреннее соглашение.Чтобы избежать таких осложнений в нашей работе, нам была необходима собственная технологическая база, которая позволила бы выполнять задачи независимо от состояния инфраструктуры на стороне заказчика.Наш стекЧтобы обеспечить стабильность, мы развернули внутреннюю связку: Self-hosted GitLab + GitLab CI + GitLab Pages. Читать далее Read more
03:45
03:24
15:50
