Deploy two independently hosted services in production at once without any downtime I have two different services. Let's say Service A and Service B. Service B is dependent on Service A. Both code bases are hosted in separate repo in Bitbucket and code bases are maintained by different teams. Service A has three backend servers and Service B has seven backend servers. I use Jenkins as a CI for code deployment. So, whenever we merge the code in master branch, Jenkins start the deployment. The process is same for Service A and Service B but they have two different Jenkins server.

Now, problem is that if Service A team deploy something in production independently with major changes in code base. Then whole application will break. Because Service B is not ready yet to compatible with the code changes of Service A. Let's say, parameters of a function has been changed where Service B is expecting a different parameter.

I am looking for a solution, where Service A code merge in master gonna happen only it is time for deployment of Service B. So, every deployment of Service B, it first deploys the code of Service A and then follows with Service B. This whole deployment will take a lot of time. Main application should not be down by this time (because once Service A is deployed then user has to wait for Service B deployment, otherwise they will face errors). 

So, I am thinking if it's possible where new deployment will happen in a separate instance When deployment is completed in that instance then it will replace the previous instance. So, code will be updated in main production without any down time or error. 

What is the recommended way to achieve this ? Can I do something with Ansible in this case ?
I think you're taking the problem on the wrong side, you may start a whole new infrastructure aside and then switch loadbalancers from blue to green, loosing sessions, breaking ongoing transactions etc.

The proper way to achieve what you're doing is coding differently, when A relasease a breaking API ni version n, a should be able to continue to answer call to api in version n-1. the usual method is to have the version in the uri or an header, for exemple:

&lt;a-host&gt;/api/1/getCustomers and &lt;a-host&gt;/api/2/getCustomerList (for exemple if n is 2). With that, you can do a rolling update of B, with backends still using api v1 and new ones using api v2.