Current constraints are pretty limiting though. For self-hosted runners I would stick with docker compose (or k8s) even for single container apps since managing config is just easier. Also docker compose is platform independent so not coupled to one CI solution, especially where an org might use multiple variants (pretty common).
I agree, the constraints are noticeable. Regarding Docker Compose, yes, you are not coupled to a specific CI, but then you are coupled with Docker company, it's a different kind of lock-in, but a lock-in nonetheless.
Agreed, although similar ‘lock-ins’ exist throughout the automation, infrastructure and application stacks. So if you run your apps in the Cloud, you are tied to their API, if you use automation tools like Terraform, that’s another form of constraint model, if you operate a particular flavour of K8s, and so it goes on. Companies pick their technical architecture ‘anchor-points’ (the things they hope to change least) and then other parts of the supporting tool chain depending on a number of factors (skill-set availability, licensing model, legacy, etc.) including CI/CD and run-time environments. For many, GitHub SCM is often a strategic platform, as for the other services from the same stable (GHA, GHAS, service containers, etc) that will vary. Pick your poison and make sure you have a sane exit strategy :-)
Service Containers are a built-in feature of GitHub Actions, meaning they are seamlessly integrated into the workflow environment, so everything lives there.
They also make your integration tests code cleaner. Your tests just assume that some environment is ready.
For local testing Testcontainers is a good option.
Current constraints are pretty limiting though. For self-hosted runners I would stick with docker compose (or k8s) even for single container apps since managing config is just easier. Also docker compose is platform independent so not coupled to one CI solution, especially where an org might use multiple variants (pretty common).
I agree, the constraints are noticeable. Regarding Docker Compose, yes, you are not coupled to a specific CI, but then you are coupled with Docker company, it's a different kind of lock-in, but a lock-in nonetheless.
Agreed, although similar ‘lock-ins’ exist throughout the automation, infrastructure and application stacks. So if you run your apps in the Cloud, you are tied to their API, if you use automation tools like Terraform, that’s another form of constraint model, if you operate a particular flavour of K8s, and so it goes on. Companies pick their technical architecture ‘anchor-points’ (the things they hope to change least) and then other parts of the supporting tool chain depending on a number of factors (skill-set availability, licensing model, legacy, etc.) including CI/CD and run-time environments. For many, GitHub SCM is often a strategic platform, as for the other services from the same stable (GHA, GHAS, service containers, etc) that will vary. Pick your poison and make sure you have a sane exit strategy :-)
Nice article! Never tried this out, where do you see benefits in comparison to testcontainers?
Both are great, btw.
Service Containers are a built-in feature of GitHub Actions, meaning they are seamlessly integrated into the workflow environment, so everything lives there.
They also make your integration tests code cleaner. Your tests just assume that some environment is ready.
For local testing Testcontainers is a good option.
Great post! Will definitely check this out.
Thanks Amrut!