Below we capture the CI/CD scenarios that we would expect with our model endpoints.
- In the
automatedbuild scenario, we capture any changes in the source code for the model server, build the new resultant docker image, push the image to the container registry, and then deploy via cloud run. This captures the CI component.
Automated builds based on changes in the
masterbranch
- In the
scheduledbuild scenario, to ensure that we pull the latest model fromwandbwe force the fastapi application to rebuild, which in turn queries the service for the latest recorded model. This ensures we are always serving the most up-to-date model at the endpoint.
Scheduled builds on
masterto update the endpoint with the latest model
These scenarios together complete the CI/CD flow by allowing us to define a very easy to reproduce structure for defining build triggers based on different branches.
For brevity's sake I did not include the abstraction in this cloudbuild.yaml however you would simply pass in a substitution variable for the $MODEL_VERSION and pass that into the cloud console for that build for that branch. You could also abstract it by the name of the branch.
This relies on Cloud Scheduler to schedule the manual trigger run
python -m venv venv
source venv/bin/activate
make installmake run
make deploy
make test
make easter
Files related to application are in the app or tests directories.
Application parts are:
app
├── api - web related stuff.
│ └── routes - web routes.
├── core - application configuration, startup events, logging.
├── models - pydantic models for this application.
├── services - logic that is not just crud related.
└── main.py - FastAPI application creation and configuration.
│
tests - pytest