"They had previously invested in a homegrown command line interface program that would run their entire environment on a continuous integration runner, but it turned out it took 15-30 minutes to get the framework up before even running a test, Chia said. There were also build failures from time-outs, and the developer of the system left the company, and nobody knew how to maintain it."
"The solution they then decided on to serve development teams is to shift left toward automated testing, and prioritize tooling and coordination. This would help them catch bugs earlier, Chia said. It would be one environment, but with multiple versions on it, which they deploy using continuous integration to run integration tests. They have developed an internal deployment tool that lets engineers select which versions they want to deploy or spin down:"
Absence of a dedicated QA environment created technical and coordination problems when testing a distributed microservices system on a shared ECS development cluster. A homegrown CLI-based framework running on CI proved slow and fragile, taking 15–30 minutes to start tests, causing timeouts, build failures, and maintenance gaps after its developer left. The organization shifted left toward automated testing, prioritized tooling and coordination, and enabled multiple versions to run concurrently in one environment. Engineers deploy versioned services via CI and an internal deployment tool that spins up ECS tasks and registers conditional proxy routing rules, allowing isolated integration tests and earlier bug detection.
Read at InfoQ
Unable to calculate read time
Collection
[
|
...
]