Continous Integration and Continuous Deployment

Comparison of continuous integration software
http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software

Improving your build process with NAnt and CruiseControl.NET
http://www.youtube.com/watch?v=d37DMsy0qko

TeamCity
http://www.jetbrains.com/teamcity/

Continuous Integration for Visual Studio Load Test via Cruise Control
http://www.youtube.com/watch?v=IBCD6CZJQ14

Building and Deploying Using NAnt
http://www.codeproject.com/Articles/38718/Building-and-Deploying-Using-NAnt

 

 

Continuous Deployment
“Amazon May Deployment Stats (production hosts & environments only) 11.6 seconds
Mean time between deployments (weekday) 1,079
Max # of deployments in a single hour 10,000
Mean # of hosts simultaneously receiving a deployment 30,000
Max # of hosts simultaneously receiving a deployment”
http://assets.en.oreilly.com/1/event/60/Velocity%20Culture%20Presentation.pdf

 

Continuous delivery
“Continuous Delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.[1] It aims at building, testing, and releasing software faster and more frequently. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.”
https://en.wikipedia.org/wiki/Continuous_delivery

Continuous Delivery Vs. Continuous Deployment: What’s the Diff?
“Continuous Delivery doesn’t mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time”
https://puppetlabs.com/blog/continuous-delivery-vs-continuous-deployment-whats-diff

Continuous Delivery
“Continuous Integration is best described in a landmark article by our Chief Scientist, Martin Fowler. Originally one of the fundamental practices outlined in the Extreme Programming (XP) methodology, Continuous Integration (CI) has become an essential ingredient for teams doing iterative and incremental software delivery.

Continuous Delivery is the natural extension of Continuous Integration: an approach in which teams ensure that every change to the system is releasable, and that we can release any version at the push of a button. Continuous Delivery aims to make releases boring, so we can deliver frequently and get fast feedback on what users care about.
‘Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.’ – Martin Fowler, ThoughtWorks Chief Scientist”
https://www.thoughtworks.com/continuous-delivery

 

Continuous Delivery, Martin Fowler, 30 May 2013
“You’re doing continuous delivery when: [1]

Your software is deployable throughout its lifecycle
Your team prioritizes keeping the software deployable over working on new features
Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
You can perform push-button deployments of any version of the software to any environment on demand”
http://martinfowler.com/bliki/ContinuousDelivery.html

 

 

Software Development Lifecycle (SDLC)

The Joel Test: 12 Steps to Better Code
“Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?
http://www.joelonsoftware.com/articles/fog0000000043.html

 

 

 

Configuration Management Tools

 

Chef is for developers, Puppet is for admins (There, that’s settled)
http://venturebeat.com/2015/07/20/chef-is-for-developers-puppet-is-for-admins-there-thats-settled/

Review: Puppet vs. Chef vs. Ansible vs. Salt
http://www.infoworld.com/article/2609482/data-center/data-center-review-puppet-vs-chef-vs-ansible-vs-salt.html

Puppet or Chef: The configuration management dilemma
http://www.infoworld.com/article/2614204/data-center/puppet-or-chef–the-configuration-management-dilemma.html

Puppet vs Chef Revisited
https://www.upguard.com/articles/puppet-vs.-chef-revisited