Once the right Sitecore module has been chosen, we need to sync all environments including developer, dev, test, prod etc.
I'm thinking whether we should include items on to TDS and patch files on configuration etc.
Is this a best practice or should we avoid it? Also not sure, how we could include to module Dlls? (I guess just include a reference to it in the web project?)
We use a bunch of Marketplace Modules within our solutions usually. The way we use them heavily depends on how well the module is maintained but the general procedure that we use is to source code control the DLL's and any patch configs associated with the module.
This allows the bits and configs to get transferred to each environment by deployment processes.
As for items, we generally will install the package once on each authoring environment and then do the appropriate publishing as described in Module documentation of any.
Normally we have a list of prerequisites for a build. On developer machines we use Sitecore Instance Manager to install Sitecore and that can install modules too.
For server environments they become part of the initial server setup, that can be either a scripted setup or a more manual one.
The only time I would put that content into source control would be if we were modifying the module for a specific project. Otherwise I would keep it out.
This is a quite open question.. My answer would be not to. Where would you stop? Example: if you install WFFM, will you integrate all changes into your source control? I guess you don't. There will be modules that are more easy to include but if you include one, you should include all. So: I would not.
I am also in the 'do not source control modules' camp but it leads to tricky situations of rolling out dependencies to the team. Especially if you then have items in your source control that reference the templates from a module.
I still haven't cracked the nut on getting that stuff deployed in a reliable automated fashion. If modules were .update packages, it's fairly simple to use the Hedgehog Sitecore Package Deployer and have it install things for you by just pushing the package over, but that would require a ZIP to UPDATE converter (which I promise myself I will build one day...)
From my perspective, I agree with most of, what is being answered, which is not source controlling modules. But you do need to source control customization done to this module.
For example, in Coveo for Sitecore, you can have custom configuration files that need to be in source control, so your customization are rolled to the various environments you have but you don't need to source control the content of the whole package.
This also makes a bit trickier, if changes are made to the module itself which break upgrade paths (we shouldn't change it right but it's not to say that this can't happen) and will cause you a lot of grief if you have to compare files from source control that shouldn't be changed at all.
From my perspective the only thing, I would suggest adding to source control other than customization are the Sitecore packages so you can share with the team which version you are using which is different from having the content of that same package referenced on the solution and add the files to source control.
This helps to keep track at least for new team members for example what packages are used on the build and where to get them from.
The question is similar to the question: "should we source control NuGet packages". I'm on a 'add to source control' camp here. I've experienced a situation where NuGet package was removed from nuget repository and I was not able to download it. Since that time I'm a big fan of commiting them to repo. Others will still have to download them anyway (from repo or from nuget).
Similar with sitecore modules. After I install modules on my local instance, I commit module's dlls and config files to repo. If I need to do some tweaks to configs I will commit tweaks too.
We source control our modules as we install them from an internal NuGet as part of our build process.
The module is first installed on our local development environment using the package installer in Sitecore and then the item changes are picked up by Git and committed to source control and synced to other environments using unicorn.
Going forward we can then upgrade any modules as we need to as the source is in a repository which outputs a NuGet file so will simply update the repo and rebuild an updated NuGet file. This is then picked up on the next deployment of the site.
In this way if modules drop off the Marketplace, need customising or upgrading we will always have a single source of truth regarding what has been installed.
