Orchestration tooling for local development and test environments
One thing I feel lacking from what has been displayed from the current tooling around Azure Service Fabric is a way to orchestrate your services and their dependencies during local development or automated testing.
The two primary situations (for my own use-case at least) would be:
- I'm a developer that needs to do some changes in Service Fabric application "Application1". A service within this application calls upon an actor or a service "fabric:/Application2/MyServiceOrActor". If I check out "Application1", perform the changes and deploy it locally to test them, it will fail unless I also know before hand about the dependency on "Application2" and deploy that first.
- I want to perform full stack testing of one of my services as a part of my continuous integration pipeline. I use an Azure Resource Manager template to spin up a new environment, then deploy my service into the environment and perform a set of tests. For services that depend on other, external services, this will fail unless every test pipeline for every service explicitly knows about, checks out, builds and deploys all dependencies manually before running the test suite.
What I would love is tooling that allows us to store our services in a centralised repository, ala Docker Hub and other registry services (private, preferably, or to allow us to run our own registries) - and then some way of defining service dependencies within the repository containing our Service Fabric application code. Then this problem could be solved with a tool like Docker Compose, that when executed pulls in our dependencies from this central repository and spins them up in the target environment so that our service can run as expected without lots of manual intervention.
Trond Arve Nordheim commented
This is somewhat related to this suggestion: http://feedback.azure.com/forums/293901-service-fabric/suggestions/7774308-packaging-system-for-applications-services
A packaging and distribution system like this, with the ability to define dependencies upon such packages from your service, would go a long way of solving this problem.