• The longer development continues on a branch without merging back to the mainline, the greater the risk of multiple integration conflicts and failures when the developer branch is eventually merged back. This is called integration hell or merge hell
• When developers submit code to the repository they must first update their code to reflect the changes in the repository since they took their copy. The more changes the repository contains, the more work developers must do before submitting their own changes
• The solution to the above issues are - frequently merging back to mainline and checking that everything is in good state, meaning we could release code
• By frequently merging back and releasing we can early detect errors and eliminate inconsistencies, it allows us
  • To lower the risks of release delaying
  • To lower time and work effort of integration
  • To reduse the cost of development

In practice we have to do the following

• Run automated unit tests in the developer's local environment before committing to the mainline
• Commit to the mainline continuously and frequently
• Apply the following set of quality control principles on build server after every commit to the mainline
  • Compile the code
  • Run the unit and integration tests
  • Run additional static analyses
  • Measure and profile performance
  • Extract and format documentation from the source code
  • Facilite manual QA processes
  • Report the results to the developers

• master — Branch name for production releases - long-lived branch
• develop — Branch name for "next release" development - long-lived branch
• feature/* — Feature branches - temporary branches
• release/* — Release branches - temporary branches
• hotfix/* — Hotfix branches - temporary branches

1. Long-lived branches are only master and develop
   • A master branch is created initially with repo
   • A develop branch is forked from master branch right after that
2. Feature branches are forked on local repo from develop branch
3. When a feature is complete it is pushed to remote repo where it is merged into the develop branch via merge request
   • Feature branches on local repo is deleted then
   • Feature branch on remote repo lives only till the moment the merge request is accepted and then it is deleted
4. A release branch is forked from develop branch and lives till the moment it is merged into master and develop branches
5. When the release branch is done it is merged into develop and master branches and then the release branch is deleted
6. If an issue in master branch is detected a hotfix branch is forked from master branch
7. Once the hotfix is complete it is merged into both master and develop branches and then the hotfix branch is deleted
   • If hotfix branch is created during the time range when release branch exists, then it is merged into master and release branches (in addition or insted of develop branch) and then the hotfix branch is deleted

• Long-lived master branch stores the official release history
  • All commits in the master branch are tagged with a version number
• Long-lived develop branch serves as an integration branch for features
• Temporary feature branches use develop branch as their parent branch
  • When a feature branch is complete, it gets merged back into develop branch
  • Feature branches should never interact directly with master branch
  • Feature branches are deleted after merged into develop branch
• Temporary release branches start the next release cycle
  • Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release
  • Release branches are forked off of develop branch once develop branch has acquired enough features for a release (or a predetermined release date is approaching)
  • No new features can be added after this point to the release - only hotfixes, documentation generation, and other release-oriented tasks should go in this release branch
  • Once release branch is ready to ship, it gets merged into master branch and tagged with a version number
  • After that release branch is merged back into develop branch, which may have progressed since the release was initiated. It’s important to merge back into develop branch because critical updates may have been added to the release branch and they need to be accessible to new features
  • Release branch is deleted after merged into develop branch
• Temporary hotfix branches are used to quickly fix bugs and patch production releases in the master branch
  • Having a dedicated line of development for bug fixes lets your team address issues without interrupting the rest of the workflow or waiting for the next release cycle
  • Hotfix branches are like release branches and feature branches except they are based on master branch instead of develop branch
  • Hotfix branches are the only branches that should fork directly off of master branch
  • As soon as the fix is complete, it should be merged into both master and develop branches (or the current release branch), and master branch should be tagged with an updated version number (indicating that it was hotfix)
  • Hotfix branches are deleted after merged into develop branch

• We need a standardized way to define pipeline specification to be able not to change this specification if we like to start using different CI/CD platforms
• We need a common and univesral way to manage different execution environments and their configurations for all the required pipeline steps - to be independent on CI/CD platforms as well

In practice we have the following

• Dozens of different CI/CD tools and platforms from different vendors, open source and not only
• No standardized way to define pipeline specification
  • The most common approach is to use yaml-based vendor specific DSL
• As docker containerization has become 'de facto' standard to run any applications, CI/CD platforms tend to use docker as the most convenient and univesral way to execute pipeline steps
  • The most common approach is to use docker in docker (DIND) to be able to setup and run services necessary for mocking application environments used in development/staging/production environments
• As a result we have to choose one of the existing CI/CD platforms (and probably be coupled to its approach to define pipeline specification). The criteria to take into account
  • Native support for yaml-based pipeline specifications as the most common way to manage pipelines
  • Native support for docker in docker as a way to execute pipeline steps
• We will use the following tools to provide examples
  • GitLab CI/CD
  • Bitbucket Pipelines
  • GitHub Actions

• We have to be able to execute the same pipeline steps both for remote (via configuring CI/CD applications) and for local (via configuring Git hooks) Git repo events
• We have to be able to parameterize pipeline steps depending on repo events

• Pipeline steps are defined as self-sufficient scripts as we can use them both in CI/CD applications and in Git hooks
• Pipeline step parameterization is done with help of environment variables
  • Scripts behavior depends on conditions derived from transferred environment variables
• Git hooks are managed by pre-commit framework

• 1: For QA interaction with local temporal deployment environments it can be identified by specific feature branch name and commit ID (like feature-ABC-XXXXXXX, where ABC is feature name and XXXXXXX is 7 digits of commit ID) ↩

• 2: For QA interaction with development temporal deployment environments it can be identified by specific feature branch name and commit ID (like feature-ABC-XXXXXXX, where ABC is feature name and XXXXXXX is 7 digits of commit ID) ↩
• 3: For QA interaction with stage deployment environments it is identified by its own constant ID (like stage) ↩
• 4: For QA interaction with pre-production deployment environments it is identified by its own constant ID (like preprod) ↩
• 5: For interaction with production deployment environments it is identified by its own constant ID (like prod or just application public domain name) ↩

• Distributed VCS: local, remote repo's
• Basic commands: init, clone, add, commit, branch, merge, pull, push
• Basic flow:
  1. check out to new branch: branch, checkout,
  2. local change cycle: add, commit, merge
  3. merge changes to remote: push, (pull request), merge

• GitLab CI/CD and GitLab Workflow
• Bitbucket Pipelines and Bitbucket Pipes
• GitHub Actions

• Building applications as Docker images
  • Docker images — portable snapshots of your environment and its dependencies
  • Dockerfile — a way to declare how a docker image should be build
  • Docker multi-stage builds - lean containers
    • TODO: more about an idea of 'Using multiple Dockerfiles in separate directories for different applications to help share common files'
  • Caching — each declaration within a Dockerfile is cached when it's first built
  • Docker registry - a way to store Docker images
  • Production-ready Docker images
    • docker-entrypoint.sh
• Running applications as Docker containers
  • Docker containers - an universal approach to running applications
• CI/CD automation
  • Using containers to do integration tests
  • Using containers in production — orchestration
    • Communication issues and container networking
    • Docker Compose
    • Kubernetes
• References
  • Concept of containers
  • What's a Linux container?
  • Docker multi-stage builds
  • Docker networking
  • TODO: more

• Mono-repo — no issues to share common parameters
• Multi-repos - there are different ways to share common parameters
  • git shared-repo
  • GitLab include
  • TODO: more about different approaches

• Create and publich (store in image registry) build image - to be used to create apps images
  • Use multi-sgaing to separate building and execution environments resulting to creation of lean app images
  • Tagging is a way to differentiate versions of your application
• Create and publich deploy image - to be used to deploy apps to different environments
  • Use parameterization to run app with different configuration in different environments
• TODO: more about other specifics