Last wednesday (18th of November 2015) I gave a small talk about my work on DD4T.NET 2.0. I've done some work on how DD4T.NET 2.0 is distributed to developers and clients. I hoped you enjoyed it, for those who weren't there enjoy it too! Here are my slides:
My start slide.
So, I'm Thijs Borst, managing consultant at Incentro. More about me here.
DD4T.NET 2.0 is almost here, how do we deliver? We need to get ready for the release. How are we getting things out there? It starts with one question...
Why? (This slide is actually animated, as seen here).
Why do we want to change the way we want to distribute thing? Easy enough, with DD4T 1.x there were different names for the same packages, different people distributing those packages and each one did this on his own machine. There was no baseline, no guide on how to do this. We (DD4T Community) wanted to change this. We'll go into detail on how we did these things next.
So how are we changing these things?
First, we changed the way people bring in new code. We split up in a development branch and a master branch. Also we split from the java side (They were in the same repo). Next we even split up each deliverable into separate repositories. This way, each deliverable has its own release cycle and versions may differ between packages from now on. This saves time releasing bugfixes or incremental builds. Before, we released the entire thing every time.
Next is Continuous Integration. Each module is now built and tested when somebody submits a pull request, when we merge into develop or master (releasing). We do not build on pull requests when there are Tridion dependencies, but that is because of security reasons. There is a hosted NuGet repository for our Tridion Dependencies, with SDL Web 8 we can build and test on Pull Request as well. This process ensures every release is built the same way and dependencies are there.
Continuous Delivery is next. Each build on the develop branch is automatically pushed as an alpha version to NuGet central repository, so when there is a new feature, or you want the latest and greatest (won't suggest this in production systems) you can get it from there. Just check "include pre-releases" in Visual Studio.
Releasing follows the same procedure, but manually.
Also we wanted to distribute the same way every time, using the same identity. You can find all DD4T packages under the DD4T user on NuGet from now on. Also the old packages are there currently, but they will be hidden when DD4T.NET 2.0 GA will be released. When hidden, people can't find them anymore through Visual Studio, but older implementations will still work. Visual Studio will still be able to download those packages.
So, I was well underway implementing all this, but then someone happened...
Siawash was also busy with development on DD4T.NET 2.0. He had a couple of problems when developing. After talking with him, we came to the conclusion the current setup was a good Continuous Integration installation, but it wasn't a good solution for local development. I needed to change some things to get things working again, but the result is awesome.
We now have a guide on local development on the wiki. We can create DD4T.NET 2.0 NuGet packages locally and install those locally on the development machine by simply hit the build button in Visual Studio. Also build numbers will increment locally so updates can be done simple enough. Explanations are on the DD4T.Core wiki.
You can see for yourself. We chose AppVeyor as a CI tool, because it integrates into GitHub. You can see a green checkmark (or a red cross) next to each pull request. When clicking on this icon, you can see the build results. Also on the main page of each module there is a build status tag on the description, which shows if the develop and master branch have been built correctly. Clicking on it shows more details.
If you have questions, don't be afraid to ask.