The document discusses continuous integration and continuous delivery. Continuous integration involves regularly merging code into a main branch and running automated tests after every commit. This prevents large, complex branches from developing. Continuous delivery aims to ensure code can be reliably released at any time by deploying code as soon as it is merged into the main branch. Best practices for continuous integration include maintaining a code repository, automating builds and tests, committing to the main branch daily, and making the build process fast. Continuous delivery best practices include automating all build, test and deployment scripts, and separating scripts for dependencies, testing, and deploying.

1. Continuous
Integration

2. What is it?
Continuous integration (CI) is the practice, in
software engineering, of merging all developer
working copies to a shared mainline several times a
day.

3. So what does that mean?
It means that we should be merging feature
branches into the main branch (master), regularly.

4. Why is it important?
The main aim of CI is to prevent us from entering
Integration Hell, caused by large unwieldy branches
with so many merge conflicts, that it's unclear as to
the working state of the app.

5. How does it work?
The concept of CI was intended to be used with
automated unit tests, written through the practices
of Test Driven Development.
Initially, this was just done on the developers local
machine before merging.
In recent times however, we tend to utilise build
servers to run these suites for us after every commit

6. What else does it do?
In addition to unit tests, CI practices now include
myriad things such as updating documentation,
static analysis, measure and profile performance,
and facilitate manual QA processes.
It also leads us into the practice of Continuous
Delivery

7. Best Practices
→ Maintain a code repository

8. Best Practices
→ Maintain a code repository
→ Automate the build

9. Best Practices
→ Maintain a code repository
→ Automate the build
→ Make the build self-testing

10. Best Practices
→ Maintain a code repository
→ Automate the build
→ Make the build self-testing
→ Everyone commits to the baseline every day

11. Best Practices (cont)
→ Every commit to the baseline should be built

12. Best Practices (cont)
→ Every commit to the baseline should be built
→ Keep the build fast

13. Best Practices (cont)
→ Every commit to the baseline should be built
→ Keep the build fast
→ Test in a clone of the production environment

14. Best Practices (cont)
→ Every commit to the baseline should be built
→ Keep the build fast
→ Test in a clone of the production environment
→ Make it easy to get the latest deliverables

15. Best Practices (cont)
→ Everyone can see the results of the latest build

16. Best Practices (cont)
→ Everyone can see the results of the latest build
→ Automate deployment

17. Continuous
Delivery

18. What is it?
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.
It aims at building, testing, and releasing software
faster and more frequently.

19. What does that mean?
Every commit to the mainline (master) should be
deployable and releaseable to the customers.
It also means we should deploy as soon as that code
is merged.

20. What are
some best
practices?

21. CODE ALL OF THE THINGS!
All of the scripts to build, test, and deploy the app
should be contained in the project itself.

22. Separate scripts
We should aim to have a bootstrap script in every
project, that sets the machine up with all the
dependencies required to run the app.
For example, bundle install, npm install, bower
install, etc

23. README!!
The README file should list any large dependencies
that need to be installed before running the
bootstrap script, and also how to install them!
Things like, ruby version, node version, database
server, etc

24. Build it
If your app requires building before it can be tested,
you should create a build script that does that
automatically.

25. Test suite
Every project should have a test suite, and a way of
running that suite.
Create a test script that runs any dependencies for
your suite, and then runs the suite itself.

26. Deployment
Deployments need to be automated
This means we need to have a scripted way of
deploying to the different environments

27. Recap Time
→ Merge regularly into common mainline
→ Run tests every commit
→ Automate everything
→ Keep it fast
→ Test in a clone of production
→ Script all of the things

28. Continuous
Integration

29. It's for
everyone