Building a Service Change Certification Pipeline

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 micro-services/container architecture, it has led to the proliferation of services.

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

oost provides a collaborative service certification platform that helps developers discover service 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.

Share workload with the Rooster — Peer-2-Peer, Real-time and Policy drivenShare workload with the Rooster — Peer-2-Peer, Real-time and Policy driven

Share workload with the Rooster — Peer-2-Peer, Real-time and Policy driven

Once Divyesh receives the change, Divyesh can test the change in the similar way and mark it as a Local Certified Change.

Received workload/service running on the team member’s Roost instanceReceived workload/service running on the team member’s Roost instance

Received workload/service running on the team member’s Roost instance

Certify workload once unit, integration testing is doneCertify workload once unit, integration testing is done

Certify workload once unit, integration testing is done

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.

See source repo details, needed for atomic commitSee source repo details, needed for atomic commit

See source repo details, needed for atomic commit

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.

Teams can see certified workloadsTeams can see certified workloads

Teams can see certified workloads