Our journey with Patterns & Practices

Our journey with Patterns & Practices started when we first saw the project on GitHub, maybe two years ago. We already had our own internal framework so we just checked what this new tool could do for us. It clearly didn’t cover all our use cases, and we would still have to use our own framework.

Then I came to Ignite in 2015, and I saw Vesa Juvonen presenting the provisioning framework. It was like “Damn, it has grown a lot!”. We started using it as nugget package. It was still not covering all our use cases, but we were migrating our code slowly. As a lot of people were using this project, we found PnP functions more tested than ours, and it was great. We still had our framework tho, but it was disappearing.

But we still had issues:– We couldn’t debug when we had a problem– We had to wait for fixes, so we copied PnP functions in our framework to fix them for ourselves– We had to go to GitHub and browse files to understand fully all we could do with this framework

1. We locally clone our fork2. When we want to do some changes, we create a branch for this change that we merge to master when it’s ready3. We have a dev branch, created from the tracked PnP-Sites-Core dev branch4. When we have something interesting to propose we create a branch, get the commits from our master branch and create the pull request

We then just have to regularly get updates from PnP repositories, and reference our fork as a submodule in other projects.

This new approach has some advantages:– Our whole team has a better understanding of how the project works– We can debug– We don’t have to wait for official fixes– We can add our own code directly into the framework– It’s exciting to take part of a bigger community