CI/CD Best Practices

Continuous Integration and Continuous Deployment (CICD) Best Practices for Pliant

Pliant Workflows and Branch Management

Introduction

Pliant offers a robust low-code/no-code automation solution that operates through user-defined "workflows". To ensure seamless version control and collaboration, Pliant integrates with Bitbucket, allowing users to store and retrieve workflows as needed. This document outlines the best practices for integrating Pliant workflows with Bitbucket to optimize the development, testing, and deployment processes.

Overview

The integration mechanism between Pliant and Bitbucket is comprehensive. When configured at the root directory, the system will push or pull all workflows, including those in sub-directories, irrespective of individual changes. This approach ensures consistency but requires careful management to avoid unintended overwrites.

Best Practices

1. Repository Setup

  • Initialize a Repository: Begin by creating a new repository in Bitbucket to house your Pliant workflows.

  • Establish a Main Branch: This branch will serve as the primary source of truth. Initially, push all existing workflows into this branch to establish a baseline.

  • Develop a Feature/Development Branch: Clone the main branch to create a 'feature/develop' branch. This branch will be used for ongoing development and testing.

2. Pliant Configuration

Creating a Git Authentication in Pliant

For seamless integration with various Git systems like Github, Bitbucket, and Gitlab, Pliant offers a universal "Git" authentication schema. This guide will walk you through setting up this authentication.

Required Fields for Authentication:

  • URL of the Git system: This is the repository URL.

  • Username: Your Git system username.

  • Password/RSA Key/Personal Access Token: Depending on the Git system you use, this could be a password, an RSA key, or a personal access token.

Optional Fields:

  • Branch: Essential if you wish to perform merges.

  • Email Address: This is for additional communication or recovery options.

Instructions for Specific Git Systems:
1. Github:

Generating a Personal Access Token:

  1. Navigate to the top-right corner of any page and click on your profile photo.

  2. From the dropdown, select Settings.

  3. In the left sidebar, click on Developer settings.

  4. Navigate to Personal access tokens.

  5. Select Tokens (classic) to generate a Personal Access Token.

Note: This token functions as the password for Pliant's authentication. Store it securely, as Github will not redisplay it. If misplaced, you'll need to generate a new token.

Repository URL Structure for Github:
<https://github.com/<username>>/<repository name>.git

2. Bitbucket:

Generating an App Password:

  1. Click on the gear icon situated at the top-right corner.

  2. Select Personal Bitbucket Settings.

  3. In the left sidebar, opt for App Passwords.

  4. On the main page, click on Create App Password and complete the form.

Note: This password is used in Pliant's authentication. Ensure its safekeeping, as Bitbucket will not redisplay it. A lost password necessitates the creation of a new one.

Repository URL Structure for Bitbucket:
<https://<username>>@bitbucket.org/path/to/repository

3. Gitlab:

Generating a Personal Access Token:

  1. In the left sidebar, click on your avatar, then choose Edit profile.

  2. On the subsequent sidebar, select Access Tokens.

  3. Click on Add new token.

  4. Provide a name and specify an expiry date for the token.

  5. If no expiry date is inputted, it defaults to 365 days from the current date.

  6. Choose the required scopes and then click on Create personal access token.

Note: This token will serve as the password in Pliant's authentication. Preserve it securely, as Gitlab won't display it again. A mislaid token requires generating a new one.

Repository URL Structure for Gitlab:
<https://gitlab.com/path/to/project>

3. Workflow Development and Management

  • Routine Updates: As you modify or create new workflows, regularly push these changes to the 'feature/develop' branch. This practice ensures that your work is consistently backed up and available to other collaborators.

  • Branching for Testing: If you require separate environments for Quality Assurance (QA) or User Acceptance Testing (UAT), create these branches from the 'feature/develop' branch. This hierarchical structure ensures that all branches have access to the latest development changes.

    • If and when changes are made to the further sub-branches, such as QA or UAT, test them thoroughly to ensure functionality. When changes are made to these branches on the Pliant system, push the flows back into the QA or UAT branch, then use Bitbucket to merge those changes into the featuare/develop branch.

      • At this point, again modify your Pliant git integration from the root folder to pull from feature/develop, and pull the flows fresh for further refinement.

4. Finalizing Workflows

  • Merging Strategy: When you're satisfied with the changes and they've passed all necessary tests, begin the merging process. Start by merging any QA or UAT branches back into 'feature/develop'. Once consolidated, you can then merge 'feature/develop' into the main branch.

  • Maintain a Clean History: Ensure that commit messages are descriptive and relevant. Before merging, consider squashing multiple commits into a single, comprehensive commit to maintain a clean and interpretable history. It is important to remember the pushing flows to a branch overwrites all flows currently there, whether they have changed or not. It is a good practice to add a message when pushing flows from Pliant to indicate what changes have been made.

Summary

Pliant Folder Hierarchy and Branch Management

Introduction

Pliant's folder hierarchy is designed to mirror the development lifecycle stages, ensuring a clear separation of workflows at each phase. This structure facilitates simultaneous modifications across different stages without interference.

Folder Structure

Assume a directory structure organized as follows:

  • /Users/branches/development

  • /Users/branches/QA

  • /Users/branches/UAT

  • /Users/branches/main

Each of these folders corresponds to a specific phase in the development process:

  1. Development Folder: This is where all new workflows and modifications are initially created and tested. It directly corresponds to the 'feature/develop' branch in Bitbucket.

  2. QA Folder: Workflows that are ready for quality assurance testing are moved to this folder. It is linked to the 'QA' branch in Bitbucket.

  3. UAT Folder: After passing QA, workflows are transitioned to the UAT folder for user acceptance testing. This folder is integrated with the 'UAT' branch in Bitbucket.

  4. Main Folder: This directory houses the finalized workflows that have passed all testing phases. It is a reflection of the 'main' branch in Bitbucket. No direct modifications are made in this folder; it solely serves as a repository for approved workflows.

Branch-Specific Integration

Each folder in Pliant's hierarchy has its own dedicated Bitbucket integration:

  • Changes made in the development folder are pushed to and pulled from the 'feature/develop' branch.

  • The QA folder synchronizes with the 'QA' branch.

  • The UAT folder is integrated with the 'UAT' branch.

  • The main folder aligns with the 'main' branch in Bitbucket.

This compartmentalized approach ensures that:

  • Workflows in each phase can be modified independently.

  • Pushing from a specific folder updates only its corresponding branch in Bitbucket.

  • Pulling into a folder retrieves workflows solely from its linked branch, ensuring no cross-contamination.

Best Practices for Folder Management

  1. Maintain Phase Integrity: Ensure that workflows are modified only in their designated folders. For instance, QA testing should exclusively occur within the QA folder.

  2. Sequential Advancement: Once workflows pass a particular phase, transition them to the next folder in the sequence. For example, after development, move workflows to the QA folder for testing.

  3. Final Approval: Only after a workflow has been vetted in the UAT phase should it be merged into the 'main' branch in Bitbucket. Subsequently, it will reflect in the main folder in Pliant.

  4. Regular Syncing: To maintain consistency, regularly synchronize each folder with its corresponding Bitbucket branch. This practice ensures that all team members have access to the latest version of a workflow at each stage.

Summary

Pliant's folder hierarchy, combined with dedicated Bitbucket branch integrations, offers a streamlined and organized approach to workflow development, testing, and deployment. Adhering to the outlined structure and best practices ensures efficient collaboration and minimizes the risk of errors.

Addendum: Multi-Account Development in Pliant with Extended Branching

The primary documentation assumes workflow development is conducted using a singular shared Pliant account. However, in scenarios where multiple Pliant accounts are in use, the folder hierarchy and branch management will differ, introducing a more granular branching structure.

Multi-Account Folder Hierarchy

In a multi-account setup, the directory structure will be organized by individual user accounts and further segmented by the development phase, as illustrated below:

  • /Users/userOne/branches/develop

  • /Users/userOne/branches/qa

  • /Users/userOne/branches/uat

  • /Users/userTwo/branches/develop

  • /Users/userTwo/branches/qa

  • /Users/userTwo/branches/uat
    ... and so forth for additional users.

Extended Branch Management Options

For this multi-account scenario, the Bitbucket branch hierarchy will be more intricate:

  • main

  • main->develop

  • main->develop->userOne

  • main->develop->userTwo

  • main->develop->qa

  • main->develop->qa->userOne

  • main->develop->qa->userTwo
    ... and so forth for additional users and phases.

Notably:

  • Users can opt-out of specific branches if they don't engage in that phase of development. For instance, if userThree doesn't participate in QA, then the branch main->develop->qa->userThree and the corresponding folder /Users/userThree/branches/qa will be absent.

  • This extended branching strategy effectively multiplies the number of required Pliant licenses based on the number of workflows in use across all branches.

Conclusion

The extended branching strategy for multi-account development in Pliant offers a granular approach to workflow management, catering to individual user roles and responsibilities. While it provides flexibility and specificity, teams must be cognizant of the increased licensing requirements and ensure clear communication to navigate the intricate branch hierarchy effectively.

Search