refactor: merge deployment service into release service

[jan-zabloudil]

Originally, I created a separate service for Deployment. However, when I wanted to update the function for sending Slack notifications (in the ReleaseService), I also needed to fetch a deployment (to show it in the notification). And in the Deployment service, I also need to get a release, which resulted in a circular dependency.

To resolve this, I decided to move the Deployment functionality into the ReleaseService.

Another solution could have been to create a "ReleaseDeployment" service, but that didn't make sense given that both release and deployment are small services.

Note: Moving it to the ProjectService would also result in a circular dependency issue.

---

It feels like a lot of changes, but it is just renaming and moving things around.

[bolshakoff]

Fair enough.

Btw, regarding deployments, I would maybe not go too hard with them. In general and especially now that they are a part of Release domain again.

I mean, if we are going to have a list of deployments (on FE and as an endpoint), that's great, and the current setup should be enough. But in the long run, it might have an even bigger potential, and much more work, and probably in a separate domain, because:

• You might want to have a nicer view of the deployments over time, over different environments, different releases etc.
• With their statuses
• And one of the most interesting things - if you integrate it all with Jira, there might be a non-trivial, but interesting view of deployments vs. Jira tickets as well.

It's great that we still have Deployment as a separate type with a separate table, but I'd rather treat it as a teaser to the above. And in the thesis it could be a nice ending, something like "Deployments have a huge potential, but we leave it for a future research." 😄