Difference between revisions of "End to end Continuous Delivery tools"

From CitconWiki
Jump to navigationJump to search
Line 2: Line 2:
  
 
'''General workflow'''
 
'''General workflow'''
-Someone checks code in to version control
+
* Someone checks code in to version control
-Checkin gets picked up by build server
+
* Checkin gets picked up by build server
-Artifact repository or source control or build tool
+
* Artifact repository or source control or build tool
-Script infrastructure: chef/puppet/custom scripts (should be version controlled)
+
* Script infrastructure: chef/puppet/custom scripts (should be version controlled)
-Deploy (Chef, Capistrano, shell scripts, manually)
+
* Deploy (Chef, Capistrano, shell scripts, manually)
-Testing
+
* Testing
-UAT /(business sign off)
+
* UAT /(business sign off)
-Deployment to Production
+
* Deployment to Production
-Monitoring/Logging (Nagios/PagerDuty/New Relic/Custom Built Solutions)
+
* Monitoring/Logging (Nagios/PagerDuty/New Relic/Custom Built Solutions)
  
  
 
'''Thoughts'''
 
'''Thoughts'''
 
Teams use their own build tools and they come together in an artifact repo. For example, 1000 people working on the app(s). Do we want everything to go to a centralized CI server, or do we want devs to be more involved? Teams can have a local CI server, but it would be nice to still have a CD workflow on the ops level.
 
Teams use their own build tools and they come together in an artifact repo. For example, 1000 people working on the app(s). Do we want everything to go to a centralized CI server, or do we want devs to be more involved? Teams can have a local CI server, but it would be nice to still have a CD workflow on the ops level.
 +
  
 
The pipeline is broken. Unless the app is architected so that any component can be changed along the way, the workflow won't be useful
 
The pipeline is broken. Unless the app is architected so that any component can be changed along the way, the workflow won't be useful
 +
  
 
Deployment contract: All apps must follow it. If so, our orchestration tool can handle it.
 
Deployment contract: All apps must follow it. If so, our orchestration tool can handle it.
 +
  
 
Facebook's deployment example: One gigantic binary and use bittorrent to get it to all of the servers and extract there. Rsync could work but it would not work sending it to thousands of machines.
 
Facebook's deployment example: One gigantic binary and use bittorrent to get it to all of the servers and extract there. Rsync could work but it would not work sending it to thousands of machines.
 +
  
 
Rationally Unified Process. There are documented processes at different contexts.
 
Rationally Unified Process. There are documented processes at different contexts.
 +
  
 
Are we okay with stitching together a bunch of tools? Over time, this may change. Use the cloud? There should be a standardized tool to deploy to the cloud.
 
Are we okay with stitching together a bunch of tools? Over time, this may change. Use the cloud? There should be a standardized tool to deploy to the cloud.
 +
  
 
Monitoring: Who finds issues first - the monitoring tools or the users?
 
Monitoring: Who finds issues first - the monitoring tools or the users?
 +
  
 
Rollbacks: Stored in the artifact repo - easy unless there is a DB schema change?
 
Rollbacks: Stored in the artifact repo - easy unless there is a DB schema change?
 +
  
 
These tools can be misused and used for generic automation.  
 
These tools can be misused and used for generic automation.  
 +
  
 
'''Questions?'''
 
'''Questions?'''
Should this be a process tool that integrates others? Plugin/template based?
+
* Should this be a process tool that integrates others? Plugin/template based?

Revision as of 09:24, 24 August 2013

Idea: A tool to open up, input the CD workflow. Does this exist? Does it need to exist?

General workflow

  • Someone checks code in to version control
  • Checkin gets picked up by build server
  • Artifact repository or source control or build tool
  • Script infrastructure: chef/puppet/custom scripts (should be version controlled)
  • Deploy (Chef, Capistrano, shell scripts, manually)
  • Testing
  • UAT /(business sign off)
  • Deployment to Production
  • Monitoring/Logging (Nagios/PagerDuty/New Relic/Custom Built Solutions)


Thoughts Teams use their own build tools and they come together in an artifact repo. For example, 1000 people working on the app(s). Do we want everything to go to a centralized CI server, or do we want devs to be more involved? Teams can have a local CI server, but it would be nice to still have a CD workflow on the ops level.


The pipeline is broken. Unless the app is architected so that any component can be changed along the way, the workflow won't be useful


Deployment contract: All apps must follow it. If so, our orchestration tool can handle it.


Facebook's deployment example: One gigantic binary and use bittorrent to get it to all of the servers and extract there. Rsync could work but it would not work sending it to thousands of machines.


Rationally Unified Process. There are documented processes at different contexts.


Are we okay with stitching together a bunch of tools? Over time, this may change. Use the cloud? There should be a standardized tool to deploy to the cloud.


Monitoring: Who finds issues first - the monitoring tools or the users?


Rollbacks: Stored in the artifact repo - easy unless there is a DB schema change?


These tools can be misused and used for generic automation.


Questions?

  • Should this be a process tool that integrates others? Plugin/template based?