This document provides an introduction to CI/CD (continuous integration/continuous delivery) processes. It defines key terms, describes how CI/CD works by automating the integration, building, testing and deployment of code changes. The benefits are listed as reducing errors, improving quality and enabling faster releases. Examples are given of tools that can be used and best practices like automating builds, testing in production-like environments and keeping everything in source control. A case study of Verizon's prepaid mobile app deployment is presented to illustrate how feature branches are merged after passing tests.

1. Introduction to
CI/CD
By Hoang Le - Sep 2018

2. Agenda
2
❏ Introduction and Definition
❏ How it works?
❏ Benefits of using CI/CD
❏ Tools and Examples
❏ Principal and Best Practices
❏ Q&A

3. Anti-patterns of Software Delivery
3
❖ Deploy Software Manually
❖ Deploying to a Production-Like environment (e.g. staging) only after development
is complete
❖ Manually configuration management for Production environment

4. Definitions
● Continuous Integration usually refers to integrating, building, and testing
code within the development environment. Continuous Delivery builds on
this, dealing with the final stages required for production deployment
● Continuous Delivery is a software engineering approach in which teams
produce software in short cycles, ensuring that the software can be
reliably released at any time. It aims at building, testing, and releasing
software faster and more frequently - Wiki
● Continuous Deployment means that every change goes through the
pipeline and automatically gets put into production, resulting in many
production deployments every day. In order to do Continuous
Deployment you must be doing Continuous Delivery
4

5. How it works?
5

6. Benefits of CI/CD
● Reduction of repetitive manual processes ➔ automate everything
● Reducing errors (e.g. human mistakes)
● Lowering stress: fast and easy to deploy / rollback
● Bugs and problems discovered closer to the point in time that they were
introduced ➔ improve productivity and quality
● System is deployable more frequently and flexibility, enabling more users
feedback ➔ reliable releases
● Improve customer satisfaction
6

7. CI/CD Tool Options
7

8. Example of CI/CD – Verizon Prepaid
● Project overview: Verizon is a web application that hosted AWS to support interface for
processing end-customer transactions through the workflow to activate Verizon Prepaid
accounts
○ Tech Stack: Node.js, Angular.js, Docker, AWS
○ Team: 4 DEV, 1 Automation Developer, 1 QA
● Development Workflow
○ Two long running branches master and develop with a transition number of feature
branches
○ Using GIT Flow
○ Workflow
■ Create feature branch from develop
■ Commits changes to the feature branch
■ Create a Pull Request (PR) targeting the develop branch
■ Merged PR after it passed CI tests and team review
■ Delete feature branch after integration is complete
8

9. Example of CI/CD – Verizon Prepaid
Integration and Development Workflow
9

10. Principals
10
• Automate the build
• Make the build self-testing
• Everyone commits to the baseline every day
• Every commit should be built
• Keep the build fast
• Test in a clone of the PROD environment
• Make it easy to get the latest deliverables
• Everyone can see the results of the latest build
• Automate deployment
Continuous
Integration
• The process for releasing/deploying software MUST
be repeatable and reliable
• Automate everything
• If somethings difficult or painful, do it more often
• Keep everything in source control
• Done means “released”
• Build quality in!
• Everybody has responsibility for the release process.
• Improve continuously.
Continuous
Delivery

11. Best Practices
● Continuous Integration
○ Don’t check-in on a Broken build
○ Always run all commit tests locally before committing, or get your CI server do it for you
○ Wait for commit test to Pass before moving on. Never go home on a Broken build
○ Time-box fixing before reverting (e.g. try to fix in 10 mins, if not then revert)
○ User TDD / BDD
● Continuous Delivery
○ Build the binaries only one
○ Deploy the same way to every environment
○ Smock test your deployment
○ Use a container technology (Docker) if possible as makes deployment simple
11

12. Thank you!
12