8 Replies Latest reply on Jun 22, 2020 5:31 AM by bjn

    Why not to use CRM.Cockpit?

    gabor.horvath Novice

      Hi Community,

       

      in the last over 10 years of my update/Aurea-history I am using CRM.Cockpit for deployment from DEV to TEST and PROD (in about 30 Aurea projects). I like it, and it makes my life much easier: the installation goes smoothly, I have "only one step" to do and I do not have to think about "what I might forgot" to deploy, or in which order should I do it.  As CRM.Cockpit was introduced years ago (with CRM v8?), it had a lots of issues, but with the time it became a very useful tool for deployments. I really thank You for it, update/Aurea!

       

      In the discussion with other Aurea Partners (or Aurea itself), I learned, that the "old update specialist" still do not use this tool: they use communication, bulkloader, batches, etc. for deployments. My question is: WHY?

      Why not to use this? If you just start a new Aurea.CRM project, why would You not choose CRM.Cockpit for deployment?

       

      I suggest everyone to try it out and use it, so I would like to learn, why You decided not to use it. I want to be prepared for discussions in the future about this, so I would like to know the "black side of CRM.cockpit" ;-)

       

      Thanks

      Gabor

        • Re: Why not to use CRM.Cockpit?
          _miki_ Novice

          Hi Gábor (Gabor Horvath),

          I find your question interesting to discuss, but for now I just want to add some thoughts for the question.

          As CRM.Cockpit was introduced years ago (with CRM v8?), it had a lots of issues, but with the time it became a very useful tool for deployments.

          Indeed, at the beginning it was just a pain to use and on the day of deployment it's not fun to analyze the cockpit.log in order to find out, what's the problem. Even if I experimented with the tool at the version of v9 to give a last chance, it was not stable enough or just simply slow for small deployments. Finally I gave up taking risk at the deployment, and for me...:

          • communication module is lightweight and rock solid, the remaining deployment items (designer config and flat files) can be transported by some batch or powershell scripts
          • the IT landscape of the most targetted customers are constantly getting bigger, so after a while they need an ARA (Automated Release Automation) tool anyway - cockpit does not stop the Application Pools of IIS and stop the Windows Service, so it' still not fully automatic, more precisely this pain point won't disappear so quickly.
          • if you want to deploy to a load-balanced server cluster, you need to execute some steps selectively and definitely adopt your automated call of cockpit.CLI
            • I hope, nobody comes up with the bad idea to hassle around with the GUI, and anyway: repetitive human tasks are faulty in a long term.
            • for (mostly ISI customers) who want to profit from the advantages of the public cloud / SaaS variant, cockpit is a no-go: you don't have, you won't have a direct access to the machine. I guess, nobody wants to pay extra for IaaS just to have Cockpit
          • I guess, in order to revive this tool you need to rebrand it, that nobody associate it with bad feelings and experiences.

           

          In the discussion with other Aurea Partners (or Aurea itself), I learned, that the "old update specialist" still do not use this tool: they use communication, bulkloader, batches, etc. for deployments. My question is: WHY?

          Furthermore this tool was barely used internally, and I can remember on the cockpit training as the only internal person, who attended it, even if many people was onboarding at that time. It does not matter whether you observe it internally or externally, cockpit has never been passionately backed by anybody, maybe you are the first person

           

          If you just start a new Aurea.CRM project, why would You not choose CRM.Cockpit for deployment?

          • As a technical consultant I would not invest more time for further trials, rather invest the time to organize my Powershell code assets for re-using it for the upcoming projects, if the customer wants to change the logic, it's simply transparent instead of an overblown zipped XML-based solution.
          • In trouble case I needed to use the good but old communication module.
          • Outlook: CI/CD (continuous integration / deployment) get into the focus, so I don't really see cockpit as a solution for the future, but find it a good idea in the past.

           

          Cheers,

          Miki

          1 person found this helpful
            • Re: Why not to use CRM.Cockpit?
              bjn Novice

              Although the COM method is "good old"..

              BUT, there are many chances to screw up the destination, especially when multiple people are using COM-transport:

              - wrong transport formats on either source or target (another collegues transport)

              - activated conditions on either source or target

              - wrong conditional output within some fields (ok, that could be fixed one time)

              - many weird command line parameters for mmco-module (see AdminGuide Aurea CRM Commands and Parameters)

              In sum:

              the person responsible for the transport has to check many things in advance to get an valid transport - but you never have the chance to look whats really inside the proprietary binary blob file.

              Even the transport-log only counts items but does not show their names/or anything else...

               

              Personally, I use the "Export/Import" buttons in the Save/Load dialogs where possible (rights, triggers, import/export formats, aso.).

              This way I can deal with human readable XML files and can compare before/after on the destination station using various tools.

               

              Still I haven't found a way to transport the datamodel as xml...

              Anyway, could you please share your "transport"-scripts ?

               

              ~Bernhard

              1 person found this helpful
                • Re: Why not to use CRM.Cockpit?
                  _miki_ Novice

                  Hi Bernhard,

                  I totally agree with your disadvantage bullet points: even if you derive your communication formats from the out-of-box/template ones, you still have some hassle at the very beginning. But after you might not change the transportation format every month, right? Mostly, the input side is unconditional - maybe with the exception of multi-tenant environments.

                   

                  the person responsible for the transport has to check many things in advance to get an valid transport...

                  That's an initial preparation step, if you setup once everything right, every beginner can start a batch file or Powershell script by a shortcut.

                  ... and personally: if someone is responsible for the deployment, I hope he knows what he's doing, he should at least. Before creating a cockpit package, he also should check if somebody in the team might forgot to include necessary items, and this is a recurring demand compared to custom communication, where you only need to take care in special cases, otherwise you "shoot" the updates to the staging/test environments within couple of seconds as usual, and if you discover a bug, you can hotfix it immediately.

                   

                  but you never have the chance to look whats really inside the proprietary binary blob file.

                  That's a huge drawback. I'd love to have a feature which serialize the blob file as XML, as you can do it with single formats.

                   

                  Personally, I use the "Export/Import" buttons in the Save/Load dialogs where possible (rights, triggers, import/export formats, aso.).

                  This practice is for me the quick-and-dirty solution for Hotfixing between 2 release dates without communication or such, and is still faster than Cockpit. Seriously, you won't create a new cockpit package in order to transport a single format.

                   

                  Anyway, could you please share your "transport"-scripts ?

                  Once I sorted out my code assets, but I haven't cleaned up the XML-driven Powershell scripts up in order to share it with the world! I'll take the interest as motivation, do the postponed job at latest at the weekend and share it on GitHub. Then I'm going to post the link to the repo as an upcoming reply.

                   

                  Cheers,

                  Miki

                  1 person found this helpful
                    • Re: Why not to use CRM.Cockpit?
                      bjn Novice

                      Personally, I use the "Export/Import" buttons in the Save/Load dialogs where possible (rights, triggers, import/export formats, aso.).

                      This practice is for me the quick-and-dirty solution for Hotfixing between 2 release dates without communication or such, and is still faster than Cockpit. Seriously, you won't create a new cockpit package in order to transport a single format.

                       

                      Best thing here is that you can use the same xml file from DEV->TEST also as import on PROD.

                      In COM you get an warning popup if you import an file intended for another station:

                       

                      And support told me in 1485097 - Communication file for destination station X -> import in station Y:

                      After checking the information that I had I would inform you that It's not recommended to do that, because if there are bidirectional communications between DEV and TEST and then at a latter time if you decided to use the same output from DEV in both TEST and PROD, It may not work or cause inconsistencies.

                      Also It could for example be that the catalog maintainance is not correct or that some data is missing.

                      If you want to do it you just should be aware of what you are doing.

                       

                      I also filed "1447608 - CRM.win Communication Log - transport details" which lead to an enhancement request : KB 43228 Better logging of error in communication log during transportation

                       

                      I am still waiting for the CRM.nextgen product compatible with salesforce and hopefully filling the "transport management" gap.

                      ACRM for the 21st century

                      https://community.jivesoftware.com/servlet/JiveServlet/previewBody/257461-102-2-581290/CRM%20Customer%20FAQ%20-%20June%2…

                        • Re: Why not to use CRM.Cockpit?
                          _miki_ Novice

                          Finally I've found some time to revise my code assets and clean it up as much as possible: GitHub - StrictLine/AuCRM-PSDeployment: Powershell automation scripts for AuCRM (Aurea CRM)

                           

                          After I'd drafted the readme for it, I noticed that the upfront demand to utilize this tool pays off by the time and preparations need to be done very precise. But after that you can deliver with this "on the fast lane" without human mistakes (e.g forget about stopping the AppPool/Windows Service).

                           

                          I would not recommend to use these scripts without founded Powershell skills, as some configuration options do not reside in the config.xml: AuCRM-PSDeployment/config.xml at master · StrictLine/AuCRM-PSDeployment · GitHub  - but if you manage to set it up for your environment, then you probably have every kind of deployment actions necessary for your developer operations.

                           

                          I appreciate feedbacks and contributions, but in the near future I'm going to focus on other topics...

                          And support told me in 1485097 - Communication file for destination station X -> import in station Y:

                          The fact, that it won't work (at least in the long term), originates from the nature of "communication" - it's actually a kind of manual replication designed for the age of offline thick clients. But I find your idea good, I also asked that question in myself: why not deploying the exact same configuration file into the production, which already has worked out for the test?

                          I guess, the implementation could not be that hard by utilizing the appropriate API methods: update.CRM SDK Reference (ReadContents/WriteContent), but would be irrational compared to the benefit.

                          1 person found this helpful
                            • Re: Why not to use CRM.Cockpit?
                              gabor.horvath Novice

                              Thanks for the scripts Miklos Moricz - in name of the community .

                               

                              In your comment You have shown my point: "I would not recommend to use these scripts without founded Powershell skills". This is why Cockpit was introduced several years ago. Lots of the Aurea customizers (shame on me ) and most of the Aurea customers does not have such a know how, so the need a tool, which you can use without deep knowledge in scripting/programming. Cockpit does also care about this problems (dependencies, references, restart of AppPool, etc.), so it is actually designed instead of such scripts. So why not to use it?!

                                • Re: Why not to use CRM.Cockpit?
                                  _miki_ Novice

                                  As for me (short answer): I've had bad experiences by using it from the very beginning v8 and v9, so I stopped using it. Despite this fact I totally agree with you , that the features of cockpit might satisfy the requirements for the vast majority of customers and compared to my Powershell script solution cockpit is a turnkey solution.

                                   

                                  But I might have overseen something in the user manual of cockpit (CRM.Cockpit_UserManual_v11_2.pdf)...

                                  Cockpit does also care about this problems (dependencies, references, restart of AppPool, etc.)

                                  Indeed?? Could you please point out to that section, which mentions how to trigger these actions? (Stopping is necessary for replacing the binaries for updateCRM_web and update.server)

                                   

                                  I guess, you meant, that cockpit substitutes the restarting of the AppPool and executing all the Bulkloader refresh steps by using its own standalone mechanism. This kind of restarting has nothing to do with the AppPools, cockpit is not even aware about these IIS or Windows services. Correct me if I'm wrong!

                                   

                                  If cockpit supports stopping and starting all the services, I might re-think using Cockpit, certainly only via CLI (Command Line Interface - provided it works as well) as I hate the remaining risk of human mistakes.

                                   

                                  PS: as far as I can see, we gathered all the arguments (pro and contra) to have an overview why and why not to use cockpit. Thanks for the initiation of this controversial discussion, Gabor Horvath! Of course, Aurean participation would have been nice, regarded to the future of this product as well...

                                  1 person found this helpful