-
Notifications
You must be signed in to change notification settings - Fork 0
DevelopingServices
To develop ViEWS 3, it is necessary to become familiar with how to develop microservices. This process includes an additional step to what you might be familiar with; the build step. Leveraging the excellent build process offered by Docker, this process is a lot smoother than many other development processes that include a compilation step, as code iterations will only trigger small layer builds that take seconds. There is, however, some bureaucracy around the process that requires you to be familiar with Docker images and docker compose.
Iterating on services and testing functionality as part of the larger system is called integration testing. While some features might require integration testing, at least to sanity-check that they wwork as they should in the larger context of the system, your primary testing during development should be unit-testing.
A new feature that can be exposed by a service should first be thought of as a testable unit of functionality in and of itself. This lets you skip the build step altogether.
Writing unit-tests for python is beyond the scope of this article. Follow these links for a complete introduction to unit testing:
Other unit testing frameworks are OK to use, but all existing tests for views 3
and related libraries use unittest.
Services that do not depend on other services, like the base_data_retriever,
can also be tested individually, without having to run the other services.
ViEWS 3 is a system of services that run in separate docker containers. The system is run using docker-compose.
When you run docker-compose up, docker spins up each service using the image
referred to by the services' image entry from the docker-compose.yaml file.
This means that to make docker-compose spin up a container using a different
version, you either have to tag a new image with the same tag, or change the
image tag in the docker-compose file. Both cases requires you to build a new
version with either the same, or a different tag.
To build a new version of an image, from one of the service repositories, you
simply have to run docker build -t $TAG .. The $TAG should be the full
image tag (including the docker namespace, repository and version-tag).
For example, if you wanted to build version 4.2.0 of the my-user/my_service
service, you would cd into my_service and run:
docker build -t views3/my_service:4.2.0 .
If you have version 4.1.0 stored locally (check using docker images), and
you didn't change and of the requirements in the requirements.txt file, this
build step should be pretty quick!
Now, if your docker-compose file contains the tag
views3/my_service:4.2.0 for creating the my-service
instance, you can simply run docker-compose up to spin up a new version that
includes your local changes!
All services (should) have CI/CD routines in place. Each service repository has
a cicd.yml file in the .github/workflows folder that describes the procedure.
For a description of CI/CD, see this article.