Definitions of critical terms used throughout the DevOps user documentation.
The following is a list of the definitions related to DevOps Intelligence:
Pipeline
: a pipeline is a combination of tools that they use in order to move their software through the development cycle and into production. Normally this means bringing together information from many disparate sources such as:
SCM
(Source Code Management) tools such as GIT and Mercurial
CI/CD/CD
(continuous integration) tools such as Jenkins, Travis-CI, Circle-CI, Team City
CI/CD/CD
Continuous Delivery tools such as Travis-CI, Spinnaker, Circle-CI
CI/CD/CD
Continuous Deployment tools which are often the same set as continuous delivery tools
Technical services:
Technical services are the basis of all elements we provide visibility to. A technical service can itself be comprised of others services. Technical services are the primary resource we focus on. Technical services are supported by a single git REPO (or more than one repository, some repositories may support more than one service); plus, they have a build and unit test (somewhere). As well, technical services can be used in one or more applications, where they are developed and managed by one team.
In addition, the Development team and Management team should normally be the same for most services, but it is not guaranteed. Normally, technical services are deployed via a kubernetes services definition (in k8s) -- Or may have just a POD definition or a replica set; or through a template in AWS/Azure/Google (if VM or non-Kubernetes based).
Cardinality
:
Repositories are associated with a single service.
Technical services can be associated with zero, one or more applications.
Applications
: an application is a higher level service. Application and Technical Service are somewhat similar and based on the approach undertaken by a given development organization they will choose what constitutes an application as they see fit. Common service used by many "applications" are likely to be grouped together as applications like a "CORE" application, or an IAM service. The granularity will likely vary, and the best statement is it would be whatever the customer feels qualifies as the granularity that fits their needs.
Tenant Roles
: Tenant level roles have little to no relationship to organization roles. A tenant level role is intentionally limited to the Administration capabilities of the system. All users who have been invited/authorized to use the system are implicitly considered tenant members. A tenant admin has the ability to invite new members, remove users as well as granting others the role of being a tenant admin as well as removing the tenant admin role from someone.