to users without human intervention The continuous building and testing of software Continuous Integration Continuous Delivery Code is continuously integrated then deployed automatically to a testing environment. There is some ‘business decision’ that is made by a human before it reaches users. Monday, 27 May 13 A primer
May 13 * Vital information is lost in the middle. * Developers need to see into the world of OPs to know when their changes have been deployed * OPs need to see if what they are deploying is going to work. That means
Production Monday, 27 May 13 * Vital information is lost in the middle. * Developers need to see into the world of OPs to know when their changes have been deployed * OPs need to see if what they are deploying is going to work. That means
TeamCity Developer Tools Code developed Production Monday, 27 May 13 * Vital information is lost in the middle. * Developers need to see into the world of OPs to know when their changes have been deployed * OPs need to see if what they are deploying is going to work. That means
TeamCity Puppet, Chef and Capistrano Developer Tools Ops Tools Code developed Production Monday, 27 May 13 * Vital information is lost in the middle. * Developers need to see into the world of OPs to know when their changes have been deployed * OPs need to see if what they are deploying is going to work. That means
TeamCity Puppet, Chef and Capistrano Developer Tools Ops Tools Code developed Production Deployment scripts and other glue Monday, 27 May 13 * Vital information is lost in the middle. * Developers need to see into the world of OPs to know when their changes have been deployed * OPs need to see if what they are deploying is going to work. That means
13 * Reports code metrics on only the latest result. Developers want to know what state the code is in as soon as possible. * Older results are lost amongst the noise of the development process. * As time goes by, older results are de-emphasized and eventually deleted from the system * All CI servers do this, including Bamboo, Jenkins, Hudson and TeamCity
#23 How Continuous Integration reports on code changes Latest state Bad builds - tests are broken Good builds - all tests work Monday, 27 May 13 * Reports code metrics on only the latest result. Developers want to know what state the code is in as soon as possible. * Older results are lost amongst the noise of the development process. * As time goes by, older results are de-emphasized and eventually deleted from the system * All CI servers do this, including Bamboo, Jenkins, Hudson and TeamCity
May 13 * Deployments are hard to find, CI reports on the very latest result only * No concept of environments and what has been deployed where * No way to see if the code has been signed off by QA * You could use labeling, commenting and other metadata tagging but its difficult to get to as the latest result is emphasized. Its not a first class concept. * In reality, deployments in CI are done by a bunch of work arounds. There is no 1 good way to do it.
#23 How Continuous Integration is used for Continuous Delivery 1.2 1.1 1.0 Latest state Monday, 27 May 13 * Deployments are hard to find, CI reports on the very latest result only * No concept of environments and what has been deployed where * No way to see if the code has been signed off by QA * You could use labeling, commenting and other metadata tagging but its difficult to get to as the latest result is emphasized. Its not a first class concept. * In reality, deployments in CI are done by a bunch of work arounds. There is no 1 good way to do it.
a good build as a version * Version is the primary holder for the metadata, such as the code changes, issues, QA status, etc * The version is then tracked as it goes through the different environments. * This is better as it tracks only information related to the deployment and is separate from the development noise
server #57 #58 Monday, 27 May 13 * Mark a good build as a version * Version is the primary holder for the metadata, such as the code changes, issues, QA status, etc * The version is then tracked as it goes through the different environments. * This is better as it tracks only information related to the deployment and is separate from the development noise
server #57 #58 v1.2 Declare the tested software as a Version Monday, 27 May 13 * Mark a good build as a version * Version is the primary holder for the metadata, such as the code changes, issues, QA status, etc * The version is then tracked as it goes through the different environments. * This is better as it tracks only information related to the deployment and is separate from the development noise
server #57 #58 Staging QA Production v1.0 v1.1 v1.2 Track the Versions as it moves between Environments v1.2 Declare the tested software as a Version Monday, 27 May 13 * Mark a good build as a version * Version is the primary holder for the metadata, such as the code changes, issues, QA status, etc * The version is then tracked as it goes through the different environments. * This is better as it tracks only information related to the deployment and is separate from the development noise
what is going to be deployed. It gets that thing from the build plan. For example, your web app. * Permissions can be controlled at a Deployment project or Environment level. Choose who can view & edit deployment projects and their environments. * Complete control over who can deploy the version to an environment
27 May 13 * Projects contain what is going to be deployed. It gets that thing from the build plan. For example, your web app. * Permissions can be controlled at a Deployment project or Environment level. Choose who can view & edit deployment projects and their environments. * Complete control over who can deploy the version to an environment
Project Environment Version Continuous Delivery Monday, 27 May 13 * Projects contain what is going to be deployed. It gets that thing from the build plan. For example, your web app. * Permissions can be controlled at a Deployment project or Environment level. Choose who can view & edit deployment projects and their environments. * Complete control over who can deploy the version to an environment
Project Environment Version Continuous Delivery Monday, 27 May 13 * Projects contain what is going to be deployed. It gets that thing from the build plan. For example, your web app. * Permissions can be controlled at a Deployment project or Environment level. Choose who can view & edit deployment projects and their environments. * Complete control over who can deploy the version to an environment
QA marked as broken or approved The builds of the commits that the Version was tested by Where the version is deployed Issues and commits in the version Monday, 27 May 13
used to created the Version Who in QA marked as broken or approved The builds of the commits that the Version was tested by Where the version is deployed Issues and commits in the version Monday, 27 May 13
used to created the Version Who in QA marked as broken or approved The builds of the commits that the Version was tested by Where the version is deployed Deploy this version to an Environment Issues and commits in the version Monday, 27 May 13
i386
smt7174
chou500
kamina_zzz
lycorp_recruit_jp
kazuhitotakahashi
tsumita
abemii
bbrbbq
kakehashi
sadnessojisan
spycwolf
yoshidashingo
tanoku
destraynor
jeffersonlam
addyosmani
brad_frost
orderedlist
csswizardry
ammeep
michaelherold
eileencodes
pauljervisheath
