5 Reasons To Stop Scripting Deployments in Your CI Server

Issue link: https://read.uberflip.com/i/1254110

Contents of this Issue


Page 0 of 2

1 WHITEPAPER www.digital.ai 5 REASONS Reasons to Stop Scripting Deployments in Your CI Server Digital.ai, we love the powerful features of Jenkins, Bamboo and other Continuous Integration (CI) tools. CI tools are great for building, unit testing and validating your applications, and indeed doing pretty much anything you want to do with code. Like all tools, though, they're not perfect for every job. When it comes to application deployments — where you need to remove servers from load balancers, stop servers, update web server content and application server binaries, run database updates, restart servers, and so on — a CI tool such as Jenkins or Bamboo often does not deliver the scalability and maintainability that you need for an efficient delivery process. AGENTS On a low-level technical note, all common CI servers are agent-based. If your target deployment servers are used for builds, you'll already have an agent running there, of course. But your QA database or application server is unlikely to be a build agent for your CI tool. Do you want to install and manage agents on all those machines? How will you ensure that build jobs — harmless or otherwise — are not run on those machines? Do you need to install Java on those machines in the first place (for example, if they're Windows boxes)? 1 CI tools are great for building and unit testing, but like all tools they are not perfect for every job. Here are some of the main challenges we've faced when trying to use CI servers for enterprise application deployment. If you're about to script out deployments in your CI server, and recognize some of the questions and challenges below, we recommend that you consider combining your CI server with a deployment automation tool before continuing.

Articles in this issue

Links on this page

view archives of Whitepapers - 5 Reasons To Stop Scripting Deployments in Your CI Server