Fundamental Structure

Here, in this section, we discuss the building blocks of Microservices Management. Right from service onboarding to deployment, here's how BuildPiper manages everything seamlessly with the help of these elements.

Building Blocks of Microservices Management

To be able to manage Microservices via the product, it is imperative to understand the core constructs of the Microservices Management approach. In this documentation, you will be exposed to the core components for managing Microservices and their relevance in the overall operations.

In BuildPiper, an Application is one of the core building blocks. An Application in BuildPiper is a segregated workspace for a small independent tech team to work on their microservices.

In order to deliver a specific functionality, an application encapsulates the following necessary constructs for a team.

• Environments
• Services
• Pipelines
• Job Templates
• Cron Jobs (coming soon)

Application (Team)

An enterprise comprises a number of technology teams that work together to deliver a specific functionality. Any enterprise would want to give segregated access to their teams. The resources within an application such as environments, pipelines, and services of one team should ideally be visible only to the members of that team and not to the other team members.

Organizations want to give restricted access to only those resources and areas that their developers want to have a view of. This avoids unnecessary confusion and helps to maintain the confidentiality of app components. Also, it

• Reduces complexity
• Provides clarity
• Avoids any confusion
• Establishes Compliance
• Improves Security

This ability to offer segregated access can be leveraged via an Application which is a Team.

Read further to know how to add an application here in this documentation.

Environments

After creating an application, you will need to onboard different services. Once the service is onboarded, a workspace is required where technology teams can work on these services. So, clearly, to set up or onboard a Service, there is a need for an environment. This environment can be considered a workspace where teams can build and deploy their services.

Tech teams generally require a combination of Dev, QA, Staging, UAT and Production environments to reliably release their code to end users. At the Application level, project administrators can create required environments, enabling their team members to work and test their services. BuildPiper enables creation of multiple named environments of a particular category. For example, 2 QA environments: one for Feature1 testing and the other for Feature 2 testing.

Environment in BuildPiper is both a logical and physical construct. When an environment is created, it asks for a Cluster and a Namespace in that cluster. It ensures that any service configured for this environment will be deployed in the provided namespace of the selected cluster only. Logically, the builds performed for an environment will be available for deployment in that environment only. If you want to build once and deploy in higher environments, then the builds will have to be promoted to higher environments.

Environment encapsulates many other very powerful features,

• Deployment Workspace: Create a deployment workspace by adding a cluster and a namespace. Secret Management via Vault: Conduct transparent secret management in your config maps and secrets by providing a vault key at the environment level.
• Publish CI/CD Reports on Sonar: Sonar auth token can be provided at the environment level and all CI reports get automatically pushed to Sonar.
• Comprehensive Manageability via Config Maps and Secrets: Very robust support for efficiently managing the config maps and secrets as a group at the environment level.
• Environment Downtime Scheduler: Schedule-based automated scale-down/scale-up of the complete Environment to save cloud costs.
• Environment Dashboards: The environment dashboards help you analyze the resource utilization of all services deployed in a particular environment. It helps you discover if the namespace limits are adequately provisioned. It also gives a comprehensive view of the health status of all deployed services.

In the industry today, there are primarily Pipeline-first products available for CI/CD. Unlike these products, BuildPiper is not based on a pipeline-first approach. The metadata for how to build and deploy is not kept in the pipelines. It is captured at the environment level so that it becomes extremely easy to visualize the build and deploy configurations.

Even if the pipelines explode, the metadata is centrally stored at the environment level. Pipelines can burst but the configurations remain set at the central place. So, it is not difficult to visualize the metadata to build and deploy. This makes things extremely easy for the developers. They simply need to pick the metadata at the environment level and use this information to build and deploy the services.

The configuration of Build and Deploy details is done at the Environment level while its execution can be carried out at the Pipeline level.

Read this documentation to know how to create a new Environment in an application.

Services

Every application team is focused on one or two functionality of the Product. For instance, in the case of an eCommerce application, “search” can be a functionality. In order to render this functionality, generally multiple microservices will be required. Each of these microservices that ultimately group together to create a functionality, is a Service for the product.

In BuildPiper, Service is a microservice that is deployed independently to make a functionality work.

For a service to work it has to be packaged (built) and then it has to be deployed in a workspace. So, whenever you configure a service, you have to Configure,

• An Environment
• Build and Deploy Details

This is how you can define a Service. Using these configuration details, a service can be built and deployed in order to make the functionality work.

“Service” in BuildPiper has a logical construct. It helps technology teams in gaining a comprehensive overview of all its details. A Service along with the Service environment gives complete visibility of the

• Build and Deployment history of service in that particular environment.
• Current Build and Deploy status of Service.
• Current Health Status of the service in a cluster.
• Deployment Analytics to identify issues causing deployment failure.

Read this documentation to know how you can,

• Onboard a Service
• Associate a Service with an Environment
• Configure Build Details
• Configure Deployment Details

Pipelines

BuildPiper Pipelines are one of the most powerful and easily configurable constructs. It draws its power from its simplicity. The Pipelines are composed of Stages and Jobs.

Stages: Stage is a group of Jobs that defines different phases in a Pipeline workflow. Each stage contains one or more jobs. When you define multiple stages in a pipeline, by default, they run one after the other.

For instance, all dev environment related Deployments details can be in one stage, QA environment related Build Deployments can be in another stage. All QA environment related approvals can be in an another stage.

BuildPiper supports different approvals (checks/questions) at stage level. This ensures successful completion of a specific stage before moving onto the next stage.

At Stage level, you can define,

• Manual Approvals- A stage will wait till the approval is given.
• Conditional Execution- Depending on what happened in the previous stages, a stage may or may not run on the basis of specified conditions.

Jobs: A Job is a series of steps that run sequentially to perform a specific task. It is the smallest unit of work that can be scheduled to run within a Pipeline.

BuildPiper supports the following Jobs during a Pipeline setup.

• Build
• Deploy
• Promote
• API Call
• Jira Ticket
• Rollback
• Integration Testing
• Trigger Pipeline
• Custom Jobs (coming soon)

Read more about Pipeline Workflow and how to set up CI/CD Pipelines here.

Job Templates and Step Catalog

BuildPiper comes packed as an out-of-the-box and ready-to-use solution. But, it can totally be re-configured and used in a customized manner. Teams have the flexibility to re-configure the behaviour and functionalities of the product via Job Templates and Step Catalogs.

BuildPiper provides Pre-configured CI/CD templates and the ability to create customised Job templates. The Default Job Templates can be used for creating custom Job templates with Jobs supported by BuildPiper. Each Job has a default set of steps via which the jobs are configured. Teams can customize the product behaviour by changing the steps within a Job.

Each Job in the Job Template has a default set of Steps for the configuration and execution of Jobs. You can either add/delete steps or change the order of step execution within a Job template. Teams can choose pre-configured steps from the Step Catalog and even create new steps in the Step Catalog. It is a powerful feature that allows teams to customize the product behaviour so that it can adapt to the customer's needs.

In addition to this, what makes Step Catalog an amazing feature is its marketplace placing. This Step Catalog instilled in the product is a public repo where anyone can view/add their additions to the Job steps using this link:https://github.com/OT-BUILDPIPER-MARKETPLACE

Read more about Job Template, default Jobs supported by BuildPiper and Step Catalog here.

Watch our Video Tutorials to know how to access BuildPiper and all its components.