Building a Pull Request Certification Pipeline with Roost
Containers are fantastic enablers for cloud-native journeys. Containerized architecture has paved the way for enhanced scalability and flexibility in applications. As an increasing number of applications are being developed with or migrated to container architecture, it has led to the proliferation of them.
Services are essential for decoupling responsibilities and leading to a more autonomous and scalable solution, but they also increase the application complexity. Validating the interoperability of these services, however, can pose a significant challenge for development teams. The interoperability of these services can be a substantial contributor to delayed-release cycles, as integration issues between services are often discovered later in the development cycle, closer to the release, and can impact release timelines.
Certifying Services with Roost Desktop
Roost provides a collaborative change certification platform that helps developers discover interaction and interdependencies’ issues much earlier in the development cycle. With the help of Roost, development teams are enabled to improve the predictability and stability of releases, enhancing developer productivity.
Suppose an application has hundreds of services, and therefore hundreds of separate repositories, managed by different teams. These services are interdependent, and the dependency graph could be pretty complex. When any service goes through a change, testing the changed service with its downstream dependencies and conducting integration testing of the entire application with that service change is required. Once this two-step testing process is complete, the next challenge is to validate the service’s change independently and verify it for release.
Roost’s collaborative service certification platform brings the entire certification pipeline into the development process. Using tools like helm or service-mesh, Roost identifies service dependencies automatically and maps them for efficient management.
Local testing with multi-node Kubernetes clusters
Suppose a developer, Bob, is working on a service change. First, he needs to test his service with the dependent services. Once he deploys his service change to Roost’s policy-driven multi-node Kubernetes cluster and completes unit and integration testing, he can certify the change locally. Roost then marks it as a Local Certified Change, while keeping the required metadata (collaboration id, source repo/commit details, patch files, timestamp, owner, and dependencies’ state, etc.).
Once Bob has the Local Certified Change, he can transfer this change to his team member, Divyesh. Divyesh is running the exact same development environment, controlled by the Roost control plane’s policies.
Once Divyesh receives the change, Divyesh can test the change in the similar way and mark it as a Local Certified Change.
Any of Bob and Divyesh team members can come to the Collaboration Activities section within the Team Dashboard and mark it as a Local Certified Change. Team members are enabled to push an atomic commit on behalf of the project owner.
The Local Certified Change pipeline can be based on the number of team members testing it. The service change can then be sent to a Roost UAT server as well as any other Kubernetes UAT server. On that UAT service, the complete application testing can be completed with hundreds of services. Once testing is completed, it can be marked as the Last Known Certified Version.
