Streamline SPFx Builds with Azure DevOps CI/CD Pipeline – Part 1: Setting Up Continuous Integration

Introduction

If you're developing SharePoint Framework (SPFx) solutions, streamlining your build process is key. In this post, we’ll walk through setting up a Continuous Integration (CI) pipeline using Azure DevOps to automatically prepare your SPFx solution whenever you push code.

Step 1: Set Up the Repo

• First, create a DevOps repository and add your SPFx source code into a dedicated folder.

Step 2: Create the CI Pipeline

• Navigate to Pipelines: In Azure DevOps, go to the Pipelines section and click Create Pipeline.

• Classic Editor: Choose the classic editor for easier configuration.

• Repo & Branch: Select your repository and branch, then continue.

 

Step 3: Configure Pipeline Jobs

• Empty Job: Choose the empty job template.

• Add Tasks:

1. Node.js Tool Installer : Set the Node.js version required for your SPFx project.
   
   
2. NPM Install: Add the npm task to install dependencies (install command).
   
   
3. Gulp Clean: Add the gulp task with clean.
   
   
4. Gulp Build: Repeat the above for build.
   
   
5. Gulp Bundle: Add another gulp task for bundle.
   
   
6. Gulp Package Solution: Finally, a gulp task for package-solution
   
   

Step 4: Handle Artifacts

• Copy Files: Add a task to copy the generated .sppkg file from the solution folder to the drop folder.

Step 5: Publish Artifacts

Add a task to publish the pipeline artifacts for the next stage.

Step 6: Set Up Triggers

In the trigger settings, define the source code path. This ensures that every commit triggers the pipeline automatically.

Conclusion:

With this setup, every push to your repository will automatically trigger the CI pipeline, ensuring your SPFx solution is built and packaged consistently.

Next Up: Part 2 – Deploy SPFx Solution to SharePoint App Catalog using Azure DevOps, we’ll cover how to automate the deployment of the .sppkg file to your SharePoint App Catalog as part of a Continuous Deployment (CD) pipeline.

If you have any questions you can reach out our SharePoint Consulting team here.

Aligning QA and Development: Strategies for Seamless Collaboration

QA (Quality Assurance) and Developers have the same goal: delivering great software. However, misunderstandings or frustrations can sometimes lead to conflicts.

Here is how to work together better:

1. Work as a Team, Not Against Each Other:

QA and Developers are not rivals. QA finds issues to improve the product, not to blame developers. Think of it as teamwork to build the best software possible.

🔹 Example: Instead of saying, "You always introduce bugs" a QA can say, "I noticed this issue - let's check it together to avoid similar ones in the future."

2. Communicate Clearly:

When reporting bugs, be specific. Instead of saying, "The feature is broken", explain what went wrong and how to reproduce it. Take screenshots, screen recordings, or logs to make things clearer.

Developers should also communicate openly if they disagree with a bug report - ask questions instead of rejecting it outright.

🔹 Example: Instead of saying, "Login is not working", say, "After entering valid credentials, clicking 'Login' causes the app to freeze. This occurs in Chrome (Version) and Edge (Version)."

3. Define Responsibilities from the Start:

Everyone should clearly understand their roles and responsibilities.

Both Developers and QA should clearly understand what needs to be developed and what needs to be tested. This prevents last-minute disagreements.

🔹 Example: Developers may think their task is complete once they implement the requirements. However, a product is truly high quality only if it is bug-free and tested for both positive and negative scenarios. Without QA, completion is not truly complete.

4. Involve QA Early in Development:

Instead of waiting until the end to test, QA should be involved from the start. This way, Developers can avoid common issues, and QA doesn't just find problems but helps prevent them.

🔹 Example: In an Agile project, QA can review requirements and suggest missing edge cases before coding starts. This helps catch issues before they become expensive to fix.

5. Use Facts, Not Opinions:

If there is a disagreement about a bug, check the logs, test reports, or user feedback.

Data helps settle arguments better than personal opinions.

🔹 Example: A Developer says, "This bug is not a big deal" but the QA shows that it crashes the app for 20% of users. Hard Facts make decisions easier.

6. Give and Accept Feedback Gracefully:

If Developer missed a bug, don't attack them - offer help to fix it.

If QA report is unclear, Developers should ask for details rather than ignore it.

Feedback should always be about improving the product, not about blaming people.

🔹 Example: Instead of saying, "You made a mistake", say, "Let's check this together to avoid similar issues in the future."

7. Work Together More Often:

Developers and QA can do joint reviews of features before testing starts. QA can explain common mistakes to developers, and Developers can show how certain parts of the code work. Pairing up can reduce misunderstandings and make bug fixing faster.

🔹 Example: Instead of Developers writing code alone and QA testing afterward, they can do a quick QA-Dev sync after each major change to catch issues early.

8. Handle Disagreements Professionally:

If there is a disagreement that can not be resolved, involve a neutral person like a QA Lead or Scrum Master. Stay focused on fixing the problem, not arguing about who is right.

🔹 Example: If QA says a bug is critical and the Developer disagrees, both can discuss with the Product Owner to decide its priority instead of arguing.

9. Celebrate Successes Together:

If a release goes smoothly or an important bug was caught early, appreciate each other's efforts.

Recognizing teamwork improves relationships between QA and Developers.

🔹 Example: A simple "Great catch!" from a Developer or "Nice fix!" from QA can improve teamwork and morale.

Final Thoughts:

🔹Conflicts between QA and Developers are normal, but they don't have to harm the team. With clear communication, teamwork, and a focus on quality, both teams can work together smoothly to build great software.

🔹Instead of seeing testing as a "blocker", Developers should see it as a way to improve their code. And QA should work with developers as partners, not critics. When both sides respect each other's roles, software quality improves, deadlines are met faster, and everyone benefits.

If you have any questions you can reach out our SharePoint Consulting team here.