I'm learning CI/CD and created a workflow for a containerized Django application. It runs the Django test suite against a PostgreSQL 14 service, builds a container image, and pushes it to a container registry using the commit SHA as the image tag. The test job currently installs dependencies, sets test database environment variables, and runs `python manage.py test`. The image job runs only after the tests pass. What would you improve regarding security, caching, triggers, image testing, and general CI design?
5 Answers
Using a temporary PostgreSQL service is a reasonable approach for integration tests, and it is often safer and more reproducible than relying on a shared development database. The concern is less about creating the container and more about what the tests do with it: keep it isolated, use throwaway credentials and data, avoid production network access, and clearly separate unit tests from database-backed integration tests. A shared test database can introduce state leakage and flaky results, so an ephemeral service is not automatically a bad design.
For a larger organization, the security team may require additional isolation or a managed test service, but the workflow itself is a common pattern for smaller applications. The important parts are least-privilege credentials, network restrictions, and keeping test data disposable.
Consider adding concurrency control if this runs on every push or pull request. When several commits are pushed quickly, older runs can continue consuming runners even though they are already obsolete. Canceling in-progress runs for the same branch or change request keeps the pipeline faster and cheaper.
The overall structure is a solid start, especially making the image job depend on the tests and limiting package-write permission to that job. A few improvements: enable dependency caching in the Python setup step, document that `DEBUG=True` and an unrestricted host value are test-only settings, and make sure they cannot accidentally be copied into a production image. Using the commit SHA as the image tag is good for traceability and rollbacks, but your deployment process needs to know how to select that exact tag. You could optionally add a human-friendly release tag as well.
Right now you test the application code, but not the container you eventually publish. Add a step that builds the image and runs a smoke test or a small integration test against that image. This can catch Dockerfile problems, missing files, incorrect working directories, and runtime dependency issues that a host-level test will not detect.
Be careful with the database password in the workflow. Even though this is a test database, credentials should come from an encrypted secret or, better yet, be generated solely for the ephemeral test service. Also review which values are stored as regular variables versus secrets, and add branch protections and environment approvals before anything can be deployed to a real environment.
I agree that integration tests belong in CI when possible. If the database schema is part of the application, creating a clean database for each run makes the tests more repeatable than depending on a long-lived shared instance.