If you have been following this blog series you will know that we have been making strides from the basics of what we are trying to accomplish under the term Enterprise Extension Development in the part one post. In parts two and three we continued the trend and talked about project structure, NuGet, and overall organization. If you have been following along since the beginning I'm sure that you have a number of questions. I know I've been getting a lot of e-mails asking about various parts of the process now that we have set up our projects in a manner that doesn't necessarily match to what you would expect for working with DNN. So let's continue the discussion with a little recap of what we have accomplished so far, then we will answer the questions.
What We Have So Far
Up to this point, we have delivered on a number of the goals that we set out with. We have a method of creating DotNetNuke projects without any need for special setup for developers to compile/manipulate. This will open the door for future discussions around unit testing and automated builds. We have decoupled our projects from any environment-specific requirements allowing any new team member to just grab the code and go for things such as packaging with MSBuild etc using the NuGet packages. We have identified a project structure process that can support larger project structures and sharing code across multiple extensions.
However, up to this point, we still have a number of questions. In this post, we are going to discuss a few of the key items. First, we will take "How do you Test/Debug?" and secondly we will look at why I recommend taking an extra step or two along the way. Before we start lets quickly look back at one of our goals in this series.
Creating a Consistent, Build Anywhere, Deployable Project
The shortest summary of what we are looking to do in this series is to make it our DotNetNuke extensions can be consistently and quickly built in any location, regardless of the individual developer specifics. What this means is we are focusing on the quality of our packages, the quality of our installation processes and not the "as it ran" code.
What this means is we want to be sure that in all cases we can create a working _installer.zip file to actually deploy our code to a DotNetNuke installation. What good would a bunch of testing do if we didn't actually test our packaging and deployment processes? Not much, we would have to re-test everything just in case we missed a file. Maybe our packaging process for some reason skipped that one little image that we needed? This process does add ever so slightly to our overall process, BUT we save time downstream.
Testing & Debugging?
Up to this point we have talked about the module structure and compiling but we haven't talked about testing or debugging. As you can imagine already we are working with projects that are now 100% decoupled from a DotNetNuke installation. We are compiling a project outside of the /DesktopModules folder. In fact, if you have been following the instructions to this point of the series only, you don't even have a local installation.
Local DotNetNuke Installation? Just Say No!
Typically when we look at a DotNetNuke guide you will see references to have a local copy of DNN running on your machine mapped in IIS to a local domain such as dnndev.me or similar. Build your modules in there and you can simply test as you go. Well, yes, this process would work GREAT for doing things quickly, but are you ever testing your install packages? What assurances do you have that you will properly deploy your solution? None! So let's take this process and refine it a bit.
As a matter of discussion, if we look at my entire DotNetNuke team at IowaComputerGurus, not a single developer has a local installation of DotNetNuke on their machines. We just don't do it. I want to be sure that we are making deployable products at all times and local installations allow you to become sloppy!
Remote Testing Installations Provide Consistency
Rather than working with a local installation that you simply compile and go, let's look at what might happen if we use a remote installation of DotNetNuke to test/debug our projects. In our case, we have a development server with at least 10 current installations of DotNetNuke that we use for module testing. With these test installations, we have various versions and editions of DotNetNuke available so we can truly test our solutions regardless if it is 6.x, 7.x, DNN Platform, Evoq Content, or otherwise we have scenarios that we can use to test.
We can deploy module packages here using the standard "Host" -> "Extensions" process, otherwise, our team has FTP access to do bulk module installations. However, no-one ever does a "Get latest" of a module into one of these test installation trees. This means that these environments, these test sites, are always using a version of a module that could be deployed to another environment, a module that had an installer to get where it is going. Something consistently repeatable. This helps to enforce process, and truly test your module. I don't need to test it in dev, then test it again just because I packaged it, I've become more efficient!
But What About Debugging?
As soon as I make this recommendation to individuals this is the first question that comes back. It is possible that we are special cases in the eco-system, however, the last time our development teams ran any module, or DNN with the debugger attached for any needed reason was more than 2.5 years ago. However, you can still debug following a process similar to this. With a remote installation, you can enable remote debugging, otherwise, you can use a local installation that is still decoupled from your development code tree and use "Attach to Process" to debug.
We don't find a lot of need for debugging in our environment, even for highly complex solutions. However, if there is interest I'll look at having a follow-up post about remote debugging and other options.
But This Process Takes Too Long!
After I get past the protest about debugging the next common complaint is that it takes too long to do things this way. At this juncture in time yes, this process will take a bit more time to go through one compile/test process, however, in future posts we will start to look at how we can automate some of these processes. How we can leverage DotNetNuke's bulk Package Installation processes to deploy multiple modules at once and make the process as streamlined as possible.
In the end, even with spending a bit more time here, we are able to have truly tested processes. Downstream, this should save you time.
Coming Up
In the next post of the series, we will talk about how under this environment we can make our lives easier. And walk through the process of actually building, deploying, and testing a module using all that we have learned from this series. Feel free to share comments and feedback below!