Contact Us
6 min read

Terms To Know To Deliver a Successful CI/CD Pipeline Project

Feb 17, 2021 8:00:00 AM

Page 20 Blog QA- Terms to Know to Deliver a Successful CICD Pipeline ProjectPicture credit: iStock

A Continuous Integration/Continuous Deployment (CI/CD) pipeline implementation project is a complex task, mostly because there are several technologies and services that need to be integrated and orchestrated. These projects often result in countless status meetings where different teams share their specific concerns and technical challenges. If they are all not on the same page with the terminology, progress can be slowed down and hard to track.

To avoid this inefficient way of working, teams must agree on using a shared vocabulary. This blog will highlight common terms and their definition that can be used directly with the application team (only one team) to gather their pipeline requirements. Using a shared vocabulary the teams agree on will help reduce confusion by making concepts and milestones clear. These terms can be developed in more detail once it is assigned to a responsible developer or team similar to any other typical Agile project.

New call-to-action

This approach will help teams kick-off and leverage extensive and complex pipeline projects with ease and gain positive feedback from their stakeholders. The main benefits of this strategy are:

  • Definition of deliverables or milestones can be directly translated into Agile stories.
  • Identification of the challenges can be translated directly into Agile spikes or POCs (Proofs Of Concept).
  • A clear definition of responsibilities among each team involved.

Please find the 16 most universal CI/CD terms below and their simple definitions:

1. Build describes any process of transforming the source code from simple text to an actual deployable unit. This can be changing a compilation, a transpilation, or packaging processes into the desired deployable unit format.

2. Build Command refers to the command or set of commands meant to be run in the build server to perform the Build process. Examples of build commands are: ./gradlew build, ./mvnw install, npm install build, gulp build, and ng build.

3. Build Server is a placeholder to reference any server that is meant to handle the build and code test process, for instance, the Jenkins build slave.

4. Build Server Provisioning references any process of creating and configuring the build server.

5. Build Tool is a placeholder that references the software required to perform the build process. Some examples are Ant, Maven, Gradle, Node.js, Py (Python), and PHP.

6. Code Testing addresses any test process that is performed as part of the build process. This can be a unit test or any isolated contract test. This also includes static code analysis tools, such as SonarQube, JSHint, Kiuwan, Klockwork, and more.

7. Deployment encapsulates the process of taking the deployable unit into the target platform and executing it to obtain running software. From the list, this concept is the most succinct because it is from the pipeline perspective. The deployment process is where you may forecast the most workload.

8. Deployable Unit refers to any file or set of files that can be deployed in the target platform. Examples of deployable units are: Docker image, Java WAR file, NPM module (package manager for the Node JavaScript platform), Angular dist folder, and JS (JavaScript) minified file.

9. Infosec Testing refers to any security-related test, manual, or automation.

10. Performance Testing is any test that’s done to verify the stability of the app once it is deployed and running.

11. Platform Provisioning alludes to the process of preparing the target platform before deployment. This can also include the provision of external services required by the application.

12. Promotion describes the act of promoting a deployable unit from a lower environment to a higher one.

13. Publication This will be the process of publishing a deployable unit from the pipeline. Some publication examples are:

  • Push a JAR file to artifactory
  • Push a Docker image to the Docker registry
  • Push an npm module to the npm registry
  • Automate the creation of a Git-tag in GitHub from the pipeline

14. QA Testing references any manual or automated validation process triggered against the deployed application that’s running in a target environment.

15. Source Code Repository (SCR) describes any source code repository solution used by the organization, such as GitHub, GitLab, Bitbucket, AWS CodeCommit, or Subversion (SVN).

16. Target Platformreferences any system, server, or running an application that is required to execute a deployable unit. Examples of target platforms are Docker host, Kubernetes, Cloud Foundry, Nginx server, Apache server, a plain Linux VM, and an Apk Registry.

Why Is Using the Right Concepts so Important?

For big organizations with hundreds of applications in the process of being developed and deployed, standardization is the best way to increase software development process efficiency. However, you cannot implement a standard procedure if there is no agreement on the standard language.

New call-to-action

How Nisum Can Help

At Nisum we have extensive experience working with high-performing organizations, and we know how to leverage pipeline and automation projects of any nature. This blog is only one example of how we ensure efficiency using the best practices for our clients. 

If your business aims to build a CI/CD pipeline, our Business Agility team can streamline your project using Agile methodology, and our Digital team can support a DevOps team to deliver reliable, high-quality development work. Contact us today to begin your DevOps transformation and help your organization achieve high-performing release velocity while using the DevOps principles of fast flow, rapid feedback, and continuous learning. 

Claudio Gallardo

Claudio Gallardo

Claudio Gallardo is an experienced Software Engineer. He started his career as a Java Developer in Nisum Latam in 2014. Later he transformed himself into a full-stack engineer. He has developed several frameworks and tools that are used by hundreds of developers to increase their productivity and enable standardization across their organization.

Have feedback? Leave a comment!

Featured

Blog by Topics

See All
6 minutos de lectura

Terms To Know To Deliver a Successful CI/CD Pipeline Project

Feb 17, 2021 8:00:00 AM

Page 20 Blog QA- Terms to Know to Deliver a Successful CICD Pipeline ProjectPicture credit: iStock

A Continuous Integration/Continuous Deployment (CI/CD) pipeline implementation project is a complex task, mostly because there are several technologies and services that need to be integrated and orchestrated. These projects often result in countless status meetings where different teams share their specific concerns and technical challenges. If they are all not on the same page with the terminology, progress can be slowed down and hard to track.

To avoid this inefficient way of working, teams must agree on using a shared vocabulary. This blog will highlight common terms and their definition that can be used directly with the application team (only one team) to gather their pipeline requirements. Using a shared vocabulary the teams agree on will help reduce confusion by making concepts and milestones clear. These terms can be developed in more detail once it is assigned to a responsible developer or team similar to any other typical Agile project.

New call-to-action

This approach will help teams kick-off and leverage extensive and complex pipeline projects with ease and gain positive feedback from their stakeholders. The main benefits of this strategy are:

  • Definition of deliverables or milestones can be directly translated into Agile stories.
  • Identification of the challenges can be translated directly into Agile spikes or POCs (Proofs Of Concept).
  • A clear definition of responsibilities among each team involved.

Please find the 16 most universal CI/CD terms below and their simple definitions:

1. Build describes any process of transforming the source code from simple text to an actual deployable unit. This can be changing a compilation, a transpilation, or packaging processes into the desired deployable unit format.

2. Build Command refers to the command or set of commands meant to be run in the build server to perform the Build process. Examples of build commands are: ./gradlew build, ./mvnw install, npm install build, gulp build, and ng build.

3. Build Server is a placeholder to reference any server that is meant to handle the build and code test process, for instance, the Jenkins build slave.

4. Build Server Provisioning references any process of creating and configuring the build server.

5. Build Tool is a placeholder that references the software required to perform the build process. Some examples are Ant, Maven, Gradle, Node.js, Py (Python), and PHP.

6. Code Testing addresses any test process that is performed as part of the build process. This can be a unit test or any isolated contract test. This also includes static code analysis tools, such as SonarQube, JSHint, Kiuwan, Klockwork, and more.

7. Deployment encapsulates the process of taking the deployable unit into the target platform and executing it to obtain running software. From the list, this concept is the most succinct because it is from the pipeline perspective. The deployment process is where you may forecast the most workload.

8. Deployable Unit refers to any file or set of files that can be deployed in the target platform. Examples of deployable units are: Docker image, Java WAR file, NPM module (package manager for the Node JavaScript platform), Angular dist folder, and JS (JavaScript) minified file.

9. Infosec Testing refers to any security-related test, manual, or automation.

10. Performance Testing is any test that’s done to verify the stability of the app once it is deployed and running.

11. Platform Provisioning alludes to the process of preparing the target platform before deployment. This can also include the provision of external services required by the application.

12. Promotion describes the act of promoting a deployable unit from a lower environment to a higher one.

13. Publication This will be the process of publishing a deployable unit from the pipeline. Some publication examples are:

  • Push a JAR file to artifactory
  • Push a Docker image to the Docker registry
  • Push an npm module to the npm registry
  • Automate the creation of a Git-tag in GitHub from the pipeline

14. QA Testing references any manual or automated validation process triggered against the deployed application that’s running in a target environment.

15. Source Code Repository (SCR) describes any source code repository solution used by the organization, such as GitHub, GitLab, Bitbucket, AWS CodeCommit, or Subversion (SVN).

16. Target Platformreferences any system, server, or running an application that is required to execute a deployable unit. Examples of target platforms are Docker host, Kubernetes, Cloud Foundry, Nginx server, Apache server, a plain Linux VM, and an Apk Registry.

Why Is Using the Right Concepts so Important?

For big organizations with hundreds of applications in the process of being developed and deployed, standardization is the best way to increase software development process efficiency. However, you cannot implement a standard procedure if there is no agreement on the standard language.

New call-to-action

How Nisum Can Help

At Nisum we have extensive experience working with high-performing organizations, and we know how to leverage pipeline and automation projects of any nature. This blog is only one example of how we ensure efficiency using the best practices for our clients. 

If your business aims to build a CI/CD pipeline, our Business Agility team can streamline your project using Agile methodology, and our Digital team can support a DevOps team to deliver reliable, high-quality development work. Contact us today to begin your DevOps transformation and help your organization achieve high-performing release velocity while using the DevOps principles of fast flow, rapid feedback, and continuous learning. 

Claudio Gallardo

Claudio Gallardo

Claudio Gallardo is an experienced Software Engineer. He started his career as a Java Developer in Nisum Latam in 2014. Later he transformed himself into a full-stack engineer. He has developed several frameworks and tools that are used by hundreds of developers to increase their productivity and enable standardization across their organization.

¿Tienes algún comentario sobre este? Déjanoslo saber!

Destacados

Blogs por tema

See All