While things are hybrid
If your monolith is difficult to deploy, requires a lot of resources, or has licensing costs even for development environments; then you'll need to limit the number of instances where the monolith lives. Your option is to create a simulator to manually do things the monolith would do so you can test the microservices, or directly manipulate data stores using your tests.
However, if your monolith is pretty easy to deploy, you can automate it's deployment as well. It would be a "bigger" service, so to speak.
You'll find that one of the key factors of success in microservices is automating the deployment as much as possible. Whether you use Chef, Salt, TerraForm, CloudFormation, containerize with an orchestration layer like Kubernetes is a choice you'll have to decide on.
There are many ways of solving this problem, but the heart of it is that you need to make your deployment and configuration as automated as possible. Some of the ways to make that easier include:
- Externalizing configuration: The deployment system pushes the configuration to the services
- Service Discovery: Either use a dedicated service discovery component, or leverage your infrastructure (i.e. DNS entries or some of the many ways that Kubernetes makes it easier to find a service)
- Protect Secrets: Secrets like usernames and passwords, or client id and secret ids for OAuth 2 authentication shouldn't be passed in the clear. You can leverage your externalized configuration if you have a means of encrypting and decrypting on the fly.
- Continuous Integration/Continuous Delivery: Every commit to the right branch or tag should build and deploy the software to the right environment.
By having deployment as part of the whole process, your question answers itself. Once you've gone through the hassle of automating the deployment and configuring the different environments appropriately, why wouldn't you just deploy your service when changes are made in all environments? That makes automated and ad hoc testing easier to do.
When you talk to large software teams like Amazon (the store front), NetFlix, AirBnB, etc. there is a common mantra. I.e. there should be one team per service. That team is responsible for everything related to the service, including deployment, testing, recovery testing, monitoring, etc. The teams would ideally be a 2 pizza team (roughly 5-8 people depending on how hungry they are).
For smaller development teams like mine, that's just not something that most companies have the luxury of doing. For example, I have two teams working for me, integrating and building out two applications into one. To handle coordination efforts, we do incorporate planning meetings with our normal scrum cadence.
- Every week we have a Scrum of Scrums, where each team lead works with the architect (me in this case), and business folks so we can resolve issues related to technology, schedule, or business priorities.
- At release planning we identify the areas we need to coordinate more tightly.
Our releases are typically 4 sprints worth of work, and then deployment to production. However, our customer has a lot more bureaucracy to release software than if we were a commercial group. Your experience may likely be different. However, I can say from experience, the more often you deploy the more critical automating that deployment is.