Continuous Integration vs Continuous Delivery vs Continuous Deployment

Continuous Integration is a term/buzzword that seems to have a clear understanding.  Continuous Delivery and Continuous Deployment on the other hand, seem to get incorrectly interchanged.

Continuous Integration

Continuously integrate changes into source control in order to test changes through automated builds and unit tests.  This provides developers with early warnings of broken code/merges and allows them to fix problems continuously.

Continuous Delivery

Some have the opinion that continuous delivery is when you deliver to a user base, such as UAT or QA.  I personally disagree.  Continuous delivery is about making sure your software is always production ready.

via Jez Humble (The guy who wrote the book… literally)

In the world of continuous delivery, developers aren’t done with a feature when they hand some code over to testers, or when the feature is “QA passed”. They are done when it is working in production.

There could be situations or reasons why you might not want or cannot deploy every good build to production.  However the idea is that every build could be released to production.

This implies continuous integration and higher level of automated testing.  It also allows Dev Ops and others outside of the development life cycle the ability to determine when to deploy to production.

Continuous Deployment

This takes continuous delivery one step further by automating deployment to a production environment.  This implies continuous integration and continuous delivery.

SQL Server Transaction Log File (LDF) Misconception

A common misconception is that setting the recovery model to simple will cause SQL Server not to use the transaction log file (LDF), preventing it from growing to an abnormal size.

In fact, the simple recovery model will still use the transaction log when performing transactions, however it will reclaims log space to keep space requirements small.

The actual file size will not be reduced by reclaiming space.  Same as performing a transactional backup will not reduce the actual file size.

This is important becase if you have a long running transaction that is performing many insert/update/delete statements, the transaction log file could grow (depending on settings) to a very large size.  Once it has grown, it will stay that size until you shrink the log file.