1

We use CD in our project and since the application is used world wide we use more than one data center (one per region). Each data center hosts an isolated instance of the application (each regional deployment uses its own DB, application server etc). Data is not shared between data centers.

There are two different approaches that we can take:

  1. Deploy to integration server (I) where all tests are run, then deploy to the first data center A and then (once the deployment to A is finished) to a data center B.

  2. Region A has a smaller user base and to prevent outage in both A and B caused by a software bug that was not caught on the integration server (I), an alternative is to deploy to the integration server and then "bake" the code in region A for 24 hours and deploy the application to data center B only after it was tested in production for 24 hours. Does this alternative go against CI best practices since there is no "continuous" deployment in this case?

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121
Nutel
  • 2,244
  • 2
  • 27
  • 50

2 Answers2

0

There is a big difference between Continuous Integration and Continuous Deploy. CI is for a situation where multiple users work on the same code base and integration tests are run repetitevely for multiple check ins so that integration failures are handled quickly and programatically. Continuous deploy is a pradigm which encapsulate deploying quickly and programmatically accepting your acceptance tests so that you deploy as quick as feasible (instead of the usual ticketing delays that exist in most IT organizations). The question you are asking is a mix for both

As per your specific question, your practice does go against the best practices. If you have 2 different data centers, you have the chance of running into separate issues on the different data centers.

I would rather design your data centers to have the flexibility to switch between current and next version. That way , you can deploy your code to the "next" environment, run your tests there. Once your testing confirms that your new environment is good to go , you can switch your environments from current to next .

Biswajit_86
  • 3,661
  • 2
  • 22
  • 36
  • Do you have a reference for the best practice that is gone against? It looks like pretty good practice to me. There are better practices, of course, but OP's case seems much better than most organisations have. (However, it's not CD by any stretch of the imagination.) – Paul Hicks May 12 '14 at 02:17
  • @PaulHicks, I do agree with your statement that OP's practices are better than many organisations. To answer your question, If soneone has a logical isolated distribution of a system which can behave separately from other such units (data centers, different set of users) and you are only deploying to a targeted small set , I will rather call it an alpha/beta release than a CD. – Biswajit_86 May 12 '14 at 02:20
  • Many organisations have no continuous anything. Unit testing, integration, UI testing.. nothing. What OP has is WAY better than that. Any many, many organisations use canary deployments. It's a valid stepping-stone on the path to proper deployment methods. It's even talked about at length in Humble and Farley. It would be better with feature flags, but something is always better than nothing, especially when trying to convince management. – Paul Hicks May 12 '14 at 02:33
0

The best practice, as Paul Hicks commented, is probably to decouple deployment from feature delivery with feature flags. That said, organizations with many production servers usually protect their uptime by either deploying to a subset of servers ("canary deployment") and monitoring before deploying to all, or by using blue-green deployment. Once the code is deployed, one can hedge one's bet further by flipping a feature flag only for a subset of users and, again, monitoring before exposing the feature to all.

Dave Schweisguth
  • 36,475
  • 10
  • 98
  • 121