CI

CI checks for the application, like

• code stability,
• code quality,
• code coverage,
• unit testing,
• security testing, and
• functional testing

Pipeline

• Pre-Deployment checks
• Code Stability
• Code Quality
• Unit Testing, Code Coverage, Security Testing
• Intermediate Operations
• Artifact Management in Continuous Integration.
• DB versioning while making database-related changes
• Post Deployment checks
  • Smoke Testing
  • Regression Testing
  • API Testing
• Notifications
• Branching Strategy

Branching strategy:

Common development branch from which developers can create their own feature branches. As soon as they are done with the features, they can raise a PR(Pull Request) for the main development branch. After the testing of features, we can raise the PR for the production branch from the development branch.

Quality Assurance (QA)

• Code stability - protects the codebase from rogue changes that might hurt more than they will help. It aims to keep the build job stable. stability of code check means checking whether code is in a compliable state or if new changes are breaking already compliable code in any way. So, in code stability, we will compile the application code to check whether it is breaking the application.
• code quality check involves keeping the code standard high.
• Unit testing - test focuses on individual features to make sure they are stable
• code coverage - metric shows how many lines of code are covered by the test cases. Having this strengthens one’s confidence in code quality. It is a sort of double-checking that raises the standard of code.
• security testing will ensure that code is not susceptible to commonly known threats. This test involves checking things like ensuring that no key is committed in the codebase, code cannot be exploited with query manipulation, and that the exceptions are handled as per security policies.

In the pull-based mechanism, our CI server will continuously poll the git repository of the application to see if there are any new changes. But in the push-based mechanism, we will configure a webhook in our git repository that will send an event to our CI server for every commit or action in the repository.

Smoke test

The term smoke testing originated from hardware development, where if you power on a circuit board for the first time and if you see any smoke rising, you’ll know it’s broken. In software development, when an application gets started, multiple user flows are executed on it to validate its basic functionality. So, smoke testing includes many benefits, like testing of basic application functionality and ease of deciding whether further testing is needed. The basic functionality varies from organization to organization. Also, it is not limited to organizations; it also includes application business logic because every application will have different logic and workflows. Selenium can be used for automated smoke testing.

the headless browser is a web browser without any GUI. We need it because our application will open on different browsers, and we have to ensure that it runs perfectly on every browser. The reason behind keeping it headless is that we are doing automated testing, and GUI will become a hindrance in that.

Regresion test

In regression testing, we verify that new code changes are not breaking anything in the existing codebase. The new changes should not influence the existing features of the product. Typically, we do regression testing when new feature is introduced, when some of the bugs are fixed, during performance improvements, and during configuration level changes.

performance testing as a part of regression testing - the rationale behind it is that there would be some changes that will impact the application performance, and no one wants a slow responsive application. So performance testing is required whenever a configuration or architecture level change is done

Regresion test: Selenium Performance test: JMeter, k6, locus

running regression and performance tests separate from the CI pipeline, in example a nightly activity

Dependency management : JFrog , Nexus Database Versioning: Liquid base, FlyWay API Testing: SoapUI, Postman API Platform, SOAtest, Swagger, Katalon Studio

CI Tools

Gitlab CI/CD

GitLab CI/CD is a tool built into GitLab for software development through the following:

• Continuous Integration (CI)
• Continuous Delivery (CD)
• Continuous Deployment (CD) GitLab CI/CD is configured by a file called .gitlab-ci.yml, placed at the repository’s root. This file creates a pipeline, which runs for changes to the code in the repository. Pipelines consist of one or more stages that run in a particular order and can each contain one or more jobs that run in parallel. These jobs (or scripts) get executed by the GitLab Runner agent.

GitHub Actions

GitHub Actions automates Software Development Life Cycle (SDLC) workflows directly in the GitHub repository, where it stores code and collaborates via pull requests and issues. We can write individual tasks, called actions, and combine them to create a custom workflow. Workflows are custom automated processes that are set up in the repository to do the following:

• Build
• Test
• Package
• Release, or deploy any code project on GitHub With GitHub Actions, you can build end-to-end continuous integration (CI) and continuous deployment (CD) capabilities directly in the repository. GitHub Actions powers GitHub’s built-in continuous integration service. Workflows run in Linux, macOS, Windows, and containers on GitHub-hosted machines called ‘runners.’ Alternatively, we can host our runners to run workflows on machines we own or manage.

Bitbucket CI

Bitbucket Pipelines is CI/CD for Bitbucket Cloud, which is integrated with the UI and sits alongside the code repositories, making it easy to get the building, testing, and deploying code up and running based on a configuration file in the repository. To set up Pipelines, we need to create and configure the bitbucket-pipelines.yml file in the root directory of the code repository. This file contains the build configuration. Using configuration-as-code means it is versioned and always in sync with the rest of the code.

Other SaaS

• TravisCI
• CircleCI
• CodeFresh
• Codeship
• Shippable
• Wercker
• Azure DevOps
• AWS DevOps

Selfhosted CI/CD Tools

• Jenkins
• TeamCity
• Bamboo
• Travis
• Circle
• Codeship

ALM application life-cycle management

ALM tools include:

• portfolio management,
• project management,
• requirements management,
• software architecture,
• application development,
• continuous integration,
• quality assurance/software testing,
• software maintenance/support,
• change management,
• release management, and
• monitoring. Example ALM Suit: Atlassian ALM suite consisting of Confluence, Bitbucket, Sourcetree,HipChat, Jira, and Bamboo.

Dictionary:

• Artifact: An artifact is a package stored in a binary repository and used for deployment to a target environment.
• Build: This means combining source code and its dependencies and creating a runnable product (artifact).
• Deploy: This means installing an artifact on a certain target environment. This can be a test environmentor a production environment.
• Promote: This activity “promotes” a release candidate to a release. The release can be deployed to a production environment. Sometimes this is an implicit step: “we now call it a release.” But in some ALM platforms it is an explicit task.
• Promote: This activity “promotes” a release candidate to a release. The release can be deployed to a production environment. Sometimes this is an implicit step: “we now call it a release.” But in some ALM platforms it is an explicit task.
• Release candidate: This is an artifact to which no new features are added anymore. Only bug fixes are solved in a release candidate, so it becomes a new release candidate again, but with a different version. If all bugs are fixed and the release candidate passes all tests, it is promoted to a release (the noun).
• Trunk: This is the main branch in a source control management system. It is also called mainline or master.
• Stage: This is a group of related activities in a CI/CD pipeline. Examples of stages are Execute build, Analyze code, and Perform test.
• Tag: A tag is used to identify a group. This group can consist of code, artifacts, stages, target resources, etc. A tag is often used to identify a release (candidate), with all its related code, CI/CD stage(s), and target resources.
• Task: This is one activity in a stage. A testing stage for example can consist of different test types,like a regression test or a preproduction test, each performed as a task.
• COTS: commercial off-the-self