Continuous integration basics

gistfile1.txt

WIKI: `In software engineering, continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day` 
as many as ten times a day

**Non-continuous integration**
 - people work in separate branches - project gets fragmented to multiple siloed branches
 - N teams working separately on a product
 - they integrate every 3 months
 - each feature is tested separately with automtaed tests and tester
 - integration stats:
   - 100 conflicts
   - 1000 lines of code that needs to be rewritten
   - ^ this becomes a completely separate new project
 - they go back to their silos, rewrite big parts ofthe code
 - meet again and merge the code
 - releases are big and unrollbackable
 
consequences:
 - tester time is wasted because he needs to re-test every feature from scratch as every feature was touched by integration
 - new project arose - merging 1000 lines is hard - since no one predicted that, it's not going to be done using
 high programming standards, management is going to want this to be deployed as soon as possible etc etc
 
 
 **Continuous integration**
  - meet every day or few times a day
  - 1 conflict
  - 10 lines
  - easy to solve
  
 consequences:
  - master (trunk branch) is healthy and tested by a human tester and automated tests as well
  - developers meet often and share knowledge
  - people care about automated tests
  - releases are small - you deliver frequently and on time
  - code is healthy
  - less time wasted
  - everything is automated (git push makes a deliverable build)
  - test suite is ran frequently - we trust the automation more (tests are ran before the deployment(
  - rollbacks are possible and easy to do 
  
**Continous integration overview**

- Prerequisites:
  - Version control software (git)
  - Code written in some testable framework or language (python, ruby, C, haskell)
  - Tests (written for the code)
  - Repository that runs tests against the code
  - A script to run tests suite (e.g. docker or just a script)
  - A CI agent (e.g. jenkins, travis, dockerhub)
  - Connection between GIT repository (github) and CI agent (Jenkins) - e.g. webhook on github
  - Several types of projects on CI agent:
   - Pull request project
   - Build project
   - Deployment project
 
 - Every push generates a POST request from github to jenkins (webhook)
 - Jenkins interprets the push from github accordingly (based on configured projects)
 - Each project receives revision (commit)
 - It checks out a commit
 - Runs a script
 - Runs a posts-build action (notify on Zulip, merge pull request or even deploy)
 
 - lg-ci-01.json
 - every project runs jobs on the basis of gihub webhooks
 - pull request jobs need an actual `test` comment or push (wont run manually)
 - every project needs:
  - build action (most likely a script from the tested repo)
  - post-build action (notification, info sent back to pull request, build or publish to aptly or docker repository etc etc)
  
  Project input:
   - code
   - project output published data or deployment artifact
   
   
   Link to graph:
   
   http://d.pr/i/qndg