Article author: Xu Ziyan, Director of Basic Platform Department of PingCode

Since the end of 2019, r&d automation products have mushroomed. In 2019, Jira acquired Code Barrel, an automation plugin developer in the app market, and launched its Jira Automate based on this plugin in March 2020. Microsoft also released Power Automate products under the Platform of Power Platform. Similarly, Asana, Clickup and others have launched their own automation products in the past two years.

In October 2020, our PingCode team officially launched its own r&d automatic exchange product Flow on the basis of investigating market trends and existing customer cases, and officially released it on May 25, 2021.

** Automated tools can greatly improve the development efficiency of r&d teams, save labor costs and reduce work errors. ** During the internal beta phase from April 12th to May 12th, we received applications from 22 customers. A total of 147 automated rules were created and executed 55,094 times during the one-month in-beta period, with an average of 1,836 rules running per day. If each rule takes 1 minute to manually operate, it saves about 30 hours of work per day, or nearly 4 person days. This shows how much automation can improve the efficiency of r&d teams.

In our last blog post, we mentioned that in order for development teams to embrace automation tools, we need to find a product that is powerful and easy to learn and use. PingCode Flow, as the first r&d automation tool in China, has a good performance in both aspects. Let’s take five minutes to automate a typical R&D scenario. It also shows you the basic functions and operations of PingCode Flow.

Scenario: Create a corresponding task for a new project startup

When starting a new project, the R&D line needs to go through the project start-up process. Within the same company or line of business, the startup tasks to be completed are basically the same. For example, our team needs to:

  • Team building and role allocation

  • Clarity of team processes and specifications

  • Application for code warehousing, server resources and pipeline

  • Code structure setup

This is a classic example of repetitive work. Because:

  • Repeat: Similar tasks are created for each project startup.

  • No design and no consideration: create the same tasks.

  • Error prone: Some tasks may be missed due to human negligence.

Such tasks are ideally suited to automated tools.

Next, let’s look at how to implement this automation rule in PingCode Flow.

Step 1: Select a trigger

In PingCode Flow, each automated rule requires an event to fire. This event could be the user setting the owner of a work item in PingCode Agile, a member joining the organization, or a new Pull Request being submitted on Github.

The trigger in PingCode Flow corresponds to these events. Therefore, when we plan an automation rule, the first thing we do is determine what events are triggered, and then select the corresponding triggers.

The current scenario is to automatically create several work items after creating a project in PingCode Agile. So we choose to create a new rule and create an automated rule.





Give the new rule a name, and then select the “Create Project” trigger, which will start the rule after the project is created. Click “OK” to create.





We now enter the edit screen for the rule, where we will add the required action steps for the rule.





Step 2: Check the type of project you are creating

In our scenario, not all projects require associated startup tasks after startup. We only need to automate scrum-type projects. So when the rule is triggered, that is, when a project is created, the first thing you need to check is whether the project type is Scrum and therefore add a “condition” to the rule.

Condition You can use Condition to determine the information when a rule is running. We can set the specific content of the condition, and only when it is satisfied (the judgment result is true), the rule will continue to execute; Otherwise, the rule terminates at this point. PingCode Flow provides different conditions for different data. For example, for a work item, a work item attribute condition can be used to determine whether an attribute of the current work item meets the requirement. The “sub-work item attribute conditions” will judge whether the sub-work items of the current work item meet our requirements.

By editing “Add Steps” at the bottom of the screen, we select “Add Condition”.





Since we want to check whether the type of project being created is Scrum, we select “Project Attribute Condition”.





In the item Attribute Condition configuration, select the type of the item to check, select the Equal operator, and compare the value to Scrum.





Attribute Type The comparison operation varies according to the attribute type selected by the user. In the current example, we support both “equal” and “not equal” operations for the type of project. In addition to “equal” and “not equal”, there are also “greater than”, “less than”, “between”, and so on, supported for time type attributes such as start time and end time of work items. There are also “empty” and “non-empty” comparisons for work item owner, priority, and other types.

With the conditional step, our rule will determine at execution whether the currently created project is of the Scrum type. Only when the Scrum project is created will the subsequent steps be performed.

Step 3: Create an epic

After judging the “project attribute conditions” above, the next step is to create an epic corresponding to the project launch effort. At the bottom of the editing screen, select Add Step and then Select Add Action.

The action we want PingCode Flow to do when a rule is executed is called an action. This action can be to set up a project leader for work or to send an email to the outside world. A rule can contain one or more actions that are executed sequentially.



We need to create an epic, a work item, in this project. So select Create Work Item.





Next, set the related properties for this work item. Here we select the work item type as “Epic”. The project that the work item belongs to is the newly created project that we get in the trigger. So in the Select project section, select from other steps.





Then select the step corresponding to the trigger in Steps.





Our trigger is “create project,” and this step gives us a lot of data (that is, fields). Here we need to select the project information corresponding to this step. In the Fields section, select Project. The work item will then be created in the same project as when the trigger fires.





Next, set the parent work item for this work item. Since we are creating an epic, it does not have a parent work item, so simply select “Do not specify”. Finally, set the title and description for the work item. Here we just write “project launch”.





This completes the first action in the rule, the creation of the work item.

Step 4: Create two features under the epic

Next, we need to create two features under this epic, one for team and rules preparation during project launch, and one for code warehousing, pipelining, and base code preparation. First, as above, select the Create Work Item action, and then set the work item type to Feature, which is still the item in the trigger.





Unlike before, this feature will be added to the epic you just created. So here we need to specify that its parent work item is “from other steps,” select the “Create work Item” step, and then select the “Work Item” field.





Finally, fill in the work item title and description.





This completes the creation of our first feature. Next, complete the second feature, which is related to the code repository pipelining application. Of course, we can create another step after this step as we did before. However, both features can be created simultaneously. Therefore, we can create this new feature on another branch by adding a branch before the current step.

The branch PingCode Flow allows you to create branches within a rule. A branch can perform multiple steps at the same time without interfering with each other. Steps in the same branch are executed sequentially. If there are “conditional” steps in a branch, adding unqualified steps (judged to be false) will only terminate the subsequent steps of the current branch without affecting the execution of other branches. Branches allow merging. The merged step is executed after all branches are completed.

If we hover the mouse over the arrow that precedes the step we just created, a plus sign will appear. Click the plus sign and select add Branch.





At this point, we see that the “Create work item” we just added is moved to the left branch, with the new branch and the new step on the right.





Similarly, we add the “Create Work Item” action, then select the work item type as “Feature”, belong to the current project, select the created epic as the parent work item, and fill in the work item title and description.





So far, our rule is this.





The three steps in this rule are called “Create work items,” which correspond to creating an epic and creating two features under an epic. You can rename them to facilitate subsequent operations. Click on the more menu to the right of the steps and select rename.





After the rename, the flow of the rule looks clearer.





Step 5: Create several user stories under the feature

Next, create more specific user stories for both the people specification and code pipelining features. To add a step under a branch, place the mouse pointer after the last step of the branch, click the plus sign and select “Add Action”.





Select Create Work Item, select User Story as the work item type, specify the project to which the trigger corresponds, and the parent work item to be the feature just created above.





Fill in the corresponding title and description. In the same way, we create several user stories that correspond to specific tasks.





In the step of “applying for code warehousing and assembly line”, the company has fixed format requirements for the name of code warehousing, that is, it must be

@ Company name/Project NumberCopy the code



Therefore, when we create this work item, we can directly generate the name of the repository and fill it into the description as required by this format. Expand the code repository request step, select the Description section, and click Add Dynamic Content on the right.





Dynamic content

Each step of rule execution involves fetching and setting data. PingCode Flow allows subsequent steps to dynamically reference the data obtained and generated in previous steps. For example, when the trigger is set to “Set work item Owner,” this step is executed with the title, number, status, and other data of the work item being acted on. They can be used in subsequent steps. If we add the “comment to work item” action, the content of the comment can refer to the data previously provided by the trigger. It is important to note that a step can only reference the data generated by the steps before it, not the ones after it. Furthermore, you cannot reference data from a step within another branch. In fact, not only do you set the work item title, description, and post comments, but the items retrieved from other steps before you set the work item are also theoretically dynamic data. Support for dynamic data is an important indicator of the flexibility of development automation tools. Making good use of dynamic data is also the key to designing efficient and simple automatic rules.

We then select the project id dynamic data provided in the Create Project step and refine the work item description.





Thus, when the rule is executed at this step, assuming that the project we created is identified as “FLOW,” the description of the work item is



@my-org/FLOW
Copy the code



Step 6: Send email notifications

As a final step, when all the work items have been created, that is, when the tasks related to the project are ready to start, you need to send an email to the person who created the project, who triggered the rule. Since this step is to be performed after all the work items have been created, that is, after the branch merge, you need to click Add Step at the bottom of the edit page and then select Add Action.

Send Mail The Send Mail action allows you to send an email to a team member’s email address or any specified email address. The header and content of the message are specified by the rule designer. This action is one of the PingCode Flow payment modules that requires you to purchase either the Team edition or the Enterprise edition.





Select Send Mail and use the dynamic data function to add a system-level rule trigger as the recipient.





Edit the subject line and content of the email. Note that we also use dynamic data here.





At this point, our rule design work is complete, click the “Save” button in the upper right corner.

Test: Create a new project

Now, let’s test our rule. Switch to the PingCode Agile module and create a new Scrum project.





Expand the requirements list and you can see that the work items related to the project launch are automatically created.





Open the “Apply code repository and pipeline” user story, and you can see that the description has generated the code repository name for us to apply for.





At the same time, as the creator of the project, who triggered this rule, we also received an email from the system.





conclusion

In just six simple steps, we completed our first PingCode Flow rule, which automatically helped us create all the tasks needed to get the project started, as well as generating the names of the code store according to company rules. If necessary, we can continue to enrich this rule by assigning principals to work items, adding followers, generating compliant pipeline and resource names, sending reminders to project members, and so on.

For space reasons, we just demonstrated the basic PingCode Flow operations involved based on this scenario. In addition, as an administrator, you can enable, disable, copy, export, and import rules, as well as view the history of rule execution.

If you are new to developing automation products and PingCode Flow, I strongly recommend that you take a look at our rule templates before manually creating rules. These templates are mature scenarios in the industry and rules we created based on our own development experience and feedback from our in-beta customers. We believe that some of the major automation issues for your r&d team have been addressed.

Finally, WE hope that PingCode Flow can help you improve your team’s work efficiency and r&d efficiency, so that your members can devote their precious time and energy to realizing the core customer value. Leave the tedious, repetitive, boring work to us.

thank you