Developer forum

Forum » Feature requests » SkipCompatibilityCheck for the Deployment Tool

SkipCompatibilityCheck for the Deployment Tool

Scott Forsyth Dynamicweb Employee
Scott Forsyth
Reply

Hello,

We often run into the deployment tool being blocked due to minor DLL differences between environments. For example, we may upgrade the dev enviornment to a new hotfix to test, but then we are no longer able to deploy with the deployment tool until production is also upgraded with the hotfix, which can many times take time until the customer signs off on upgrading production.

I created a PR (here: PR:1653) using a globalsetting to SkipCompatibilityCheck. If that's worth considering, it would be great to have that approved.

However, it could be implemented using other settings instead, or possibly with a warning rather than a blocking error. But, I hope that this doesn't get lost in becoming a big feature. We simply need to skip that check since we're aware of the differences and typically don't mind deploying with minor hotfix differences.

Thanks,

Scott


Replies

 
Nicolai Pedersen Dynamicweb Employee
Nicolai Pedersen
Reply

Hi Scott

Thank you for the pull. What about a change that is default behavior that works like this:

  1. Only check Dynamicweb and Dynamicweb.Ecommerce assemblies
  2. Only ensure they match on minor version (9.10.12 vs 9.10.14 = ok because both are 9.10 minors.)
  3. Fail still if minor does not match
public override Dictionary<string, string> GetSystemInformation()
        {
            var info = new Dictionary<string, string>();

            var assemblies = AppDomain.CurrentDomain.GetAssemblies().Where(assembly => (assembly.GetName().Name.Equals("Dynamicweb") || assembly.GetName().Name.Equals("Dynamicweb.Ecommerce")));

            foreach (var assembly in assemblies)
            {
                var name = $"Assembly {assembly.GetName().Name}";
                var version = assembly.GetCustomAttribute<AssemblyInformationalVersionAttribute>()?.InformationalVersion ?? assembly.GetName().Version.ToString();
                Version assemblyVersion = new Version(version);
                info.Add(name, $"{assemblyVersion.Major}.{assemblyVersion.Minor}");
            }

            return info;
        }

Using this, updating all kinds of supporting packages will not affect the deployment check - only the major things. I have left out Admin because that will never be out of sync compared to Dynamicweb and Dynamicweb.Ecommerce anyways, so it will have no additional effect.

 
Morten Bengtson Dynamicweb Employee
Morten Bengtson
Reply

My thoughts...

The change should probably be done in the VerifyCompatibility method instead of GetSystemInformation.
That would make it possible to introduce a setting for "compatibility sensitivity mode" (high/medium/low) which looks at the information provided by source and destination and decides what "compatible" means based on the selected "compatibility sensitivity mode".
Also, we should probably still verify that the deployment api has the same version (at least major and minor) on both source and destination (Dynamicweb.Admin (api controller) + Dynamicweb.Deployment.*).

/Morten

 
Scott Forsyth Dynamicweb Employee
Scott Forsyth
Reply

Thanks Nicolai and Morten.

That makes sense to me to have that in the VerifyCompatiblity method. Would you like for me to shift that?

I also like the idea of checking major and minor versions of at least Dynamicweb.Deployment.*. That would at least prevent real breaking changes without being too agressive. 

It's not uncommon for us to try to deploy across something like 9.9.6 to 9.10.12 (minor version), so it would be nice if it doesn't prevent all minor version updates, and only if the Deployment tool itself has updated.

For next steps, what do you recommend? I don't mind moving the Skip flag into the VerifyCompatibility method. With Nicolai's code sample, I could take a stab at checking major and minor differences in Dynamicweb.Deployment.* and Dynamicweb.admin. I like still having the global settings flag so that we can override it if needed, at our own risk. 

Scott

 

You must be logged in to post in the forum