CODEWITHSUNDEEP
jenkinscontinuous-deploymentdistributed-systemcontinuous-deliveryautomated-deployment
VinothNair
VinothNair

Reputation: 634

Automating deployments of large distributed client server application part of CI / CD

For one of our application we are trying to automate the deployment process. We have end to end Continuous Integration implemented (Build/Test/Package/Report) for this application. Now we are trying to implement the automated deployment. This application needs to be deployed in 2000 servers and 50 clients under each server. Some of the components will be installed on the server and some of them will be installed on the client.
Tools used for CI: Jenkins, Github, msbuild, nunit, specflow, wix.

I have read the difference between continuous delivery and continuous deployment and understood that continuous delivery means the code/change is proven to go to live at any point of time and continuous deployment means the proven code/change will be automatically deployed to production server.

Most of the articles on the net explain how we can automate the deployments part of continues delivery / deployment to one of the servers (DEV/Staging/Preproduction/production). None of the article talks about deploying the application to large number of servers and clients.

Now my questions are 1) Deploying application to 2000+ servers and clients is part of continuous deployment or it should be handled out of CI/CD? 2) If it can be handled within CI/CD then how do I model this in the Jenkins delivery pipeline and trigger the deployment for all the servers from the CI tool? 3) Is there any tool which I can integrate with the CI tool to automate the deployment?

Thanks

Upvotes: 0

Views: 1343

Answers (2)

Dan Cornilescu
Dan Cornilescu

Reputation: 39814

I'd keep separate these 2 aspects:

  1. deployment on a large number of servers (it doesn't matter if the artifacts to deploy come from CI or not)
  2. hooking up such deployment into CI to perform CD

For #1 - I'm sure there are profesional IT tools out there that could be used. Check with your IT department. If deployment does't require superuser permissions or if you have such privileges (and knowledge) you could also write your own custom deployment/management tools.

For #2 - CD doesn't really specify if you should deploy to a single server, a certain percentage of your production servers or all of them). Your choice should be based on what makes sense or is more appropriate for your particular context. How exactly it's done if you decide to go that way? It really depends on #1 - you just need to trigger the process from your CI. Should be a breeze with a custom deployment tool :)

Upvotes: 1

Yuri G.
Yuri G.

Reputation: 4648

  1. The key requirement (IMHO) in Continuous Deployment is the process orchestration, jenkins isn't ideal tool for this, but you can write an own groovy script wrapper or to invoke the jobs remotely form an another orchestration tool. Another issue in jenkins, at least for me, is the difficulty to track the progress.

  2. I would model it as the following:

    • Divide the deployment process to logical levels, e.g Data centers->Application->Pools and create a wrapper for each level. It will allow you to see the progress at highest level in the main wrapper and drill down in case of need as you wish
    • Every wrapper should finish as SUCCESS only if ALL downstream jobs were SUCCESSFUL, otherwise it should be UNSTABLE or FAILURE . In this case there is no chance that you will miss something at the low level jobs.
    • 1 job per 1 per product/application/package
    • 1 job to control the single sequence run. For example I would use mcollective to run the installation job sequentially/parallel on the selected servers
    • 1 wrapper job for every logical level

  3. I would use:

    • mcollective - as mentinoed above
    • foreman to query the puppet to select the servers list for every sequence run
    • The package/application/artifact installation on the server I would prefer to do with a native OS software, e.g yum on the linuxserves. It will allow you to rely on their mechanism of installation verification

I'm sure that I missed something but I hope it will give you an acceptable start point

Upvotes: 0

Related Questions