Maximo

Maximo

Come for answers, stay for best practices. All we're missing is you.

 View Only
Expand all | Collapse all

Automation Script source control

  • 1.  Automation Script source control

    Posted Wed March 15, 2023 02:07 PM

    Hi all,

    Seeing how others are managing their automation script source control.  We don't have a good process to see previous version or best way to keep version history with many developers in the system.  Any feedback would be great.

    -Teng



    ------------------------------
    Teng Moua
    ------------------------------

    #Maximo
    #AssetandFacilitiesManagement


  • 2.  RE: Automation Script source control

    Posted Wed March 15, 2023 02:11 PM
    Edited by System Admin Wed March 22, 2023 11:43 AM

    At ITS we use GitHub for scripts, report design files, and a handful of other things. I have some tooling to populate the repo locally and then do a push.

    I'm working toward a set of Automation Scripts to interface with GitHub directly, but it's not quite ready for prime time yet.



    ------------------------------
    Tim Ferrill
    Solutions Consultant
    Intelligent Technology Solutions
    tferrill@webuildits.com
    www.webuildits.com
    @tferrill/@webuildits
    ------------------------------



  • 3.  RE: Automation Script source control

    Posted Wed March 15, 2023 08:11 PM

    Teng,

     

    We have done a lot of work around this and developed freely available tooling to enable using Git (Github/Azure DevOps / GitLab, really whatever).

     

    You should check out our VS Code extension here:

    https://marketplace.visualstudio.com/items?itemName=sharptree.maximo-script-deploy

     

    It lets you develop in VS Code and directly deploy to Maximo.

     

    And then we have a NodeJS NPM package for deploying from the command line.

     

    https://www.npmjs.com/package/maximo-dev-tools

     

    We also have developed Azure DevOps pipelines to fully deploy automation scripts, Java customizations and other configurations to Maximo. This includes versioning artifacts and rebuilding and redeploying the EAR. The time savings both in just not having to attend the EAR builds and having a reproducible process are significant.  Feel free to reach out if you have any questions or want to see how it is done.

     

    Cheers,
    Jason

     

    Jason VenHuizen

    CEO

     

    +1-206-669-6430 | sharptree.io

     






  • 4.  RE: Automation Script source control

    Posted yesterday

    Hello Jason,

    my customer has been testing your tooling and they do have couple of questions:

    • more detailed documentation, namely troubleshooting part, they just see http 404 and could not find any description, or guidance.
    • the same is valid for configurations - again they see it difficult to build required configurations.
    • some practical exmaples how to compile changes and deploy them
    • is there any airgapped scenario available?
    • regarding usage in highly security sensitive customers. -military etc - who owns the code ? was the code somehow audited and guaranteed ?

    Thank you 



    ------------------------------
    JAN FLEGR
    ------------------------------



  • 5.  RE: Automation Script source control

    Posted yesterday

    Hi Jan,

    I am not entirely certain which tooling you are describing, but I am going to guess it is the VS Code extension.  

    There is a lot of documentation on it here: https://marketplace.visualstudio.com/items?itemName=sharptree.maximo-script-deploy

    For the 404 error you describe, can you provide more context regarding the error.  Are you getting a 404 when trying to access documentation or is this in relation to trying to deploy something to Maximo? If the later, it would indicate that your Maximo connection details are incorrect as it is returning an error stating that the site cannot be found.

    If you have specific questions I am happy to answer them, but it is hard to guess which configurations you are having trouble with given the description of the problem.

    You are asking about compiling examples, which makes me wonder if you are not referencing the VS Code extension since its primary purpose is to deploy automation scripts, which are not compiled. If you have more specific questions I will do my best to answer them or provide specific examples.

    Nothing that we publish requires an internet connection other than to get the tools, even the VS Code extension can be downloaded and manually installed from the visx package provided by Microsoft.

    The code is open source and you can review it, compile it and branch it as you see fit. https://github.com/naviam-io/vscode-autoscript-deploy

    If you do find security issues or concerns please let me know as we do our best to keep it up to date and patch any vulnerabilities.

    Regards,
    Jason



    ------------------------------
    Jason VenHuizen
    Naviam
    https://naviam.io
    https://opqo.io
    ------------------------------



  • 6.  RE: Automation Script source control

    Posted Fri March 17, 2023 04:09 AM

    We had a similar problem and beneath urging our developers to use the script repo, i installed a backup solution that writes every script change to a (second) script repository. So we have one working repository and one where the backup is made.

    For that we included Eclipse JGit in our installation and the handling is basically done by two scripts. One that listens onadd/onupdate/ondelete on AUTOSCRIPT (you need to manually create the launchpoint, you can't do this via UI) and triggers an asynchronous script. Having the logic in this script would lead to looong savetimes while the repo is fetched, commited and pushed.

    We had to extend the ASYNCSCRIPT object by a few fields so the asynchronous script still knows what happend with the script, but that is basically all. The AsyncScript is so nice that it gives you every attribute that is not standard to all scripts it is calling and you just need to read them in your script. For an attribute ONADD you can do an "onAdd = ONADD.asBoolean()" and have the value. Now on every change of an automation script our script registers the change, creates an AsyncImmediateJob and the AsyncJob reads the changes and pushes this to the backup-repo with commit message like "ABRIEKE changed Script CXTEST".

    There is a second script running that makes a daily backup of all scripts (to the same backup repo) to catch all scripts where the automatic failed, because adminmode was on or things like that.

    Regards,

    Andreas



    ------------------------------
    Andreas Brieke
    IT Service Management Consultant
    SVA System Vertrieb Alexander GmbH
    ------------------------------



  • 7.  RE: Automation Script source control

    Posted Mon March 20, 2023 08:25 AM

    As was mentioned here already you need a source control system. Having processes around things like code review for example are critical to catching issues before they're deployed.

    Having said that, it's not flashy but e-audit is your friend. We came up with a standardized list at my previous job of tables & columns we needed to audit (AUTOSCRIPT, SCRIPTLAUNCHPOINT, REPORTDESIGN, MAXPRESENTATION, MAXATTRIBUTECFG, etc.) so we could see who made a change, what change was made, when the change was made, and know what we needed to do to be able to revert if necessary. This is the "catch all" bucket and it works in all situations.



    ------------------------------
    Steven Shull
    ------------------------------



  • 8.  RE: Automation Script source control

    Posted Tue March 21, 2023 10:28 AM

    I generally like the e-audit approach, but it might be a little bit eager to say e-audit works in all situations.

    During development in Dev, e-audit will log each and every save. However, it will eventually be someone's job, and not necessarily that of the developer, to make a Migration Manager package and deploy it to Prod, or to copy/paste the updated code into Prod. The MM approach may preserve who made the last change and when, but the copy/paste approach will not. And either way, however many saves there were in Dev, they will be reduced to just 1 save in Prod -- possibly with an inaccurate change by/date. And eventually, Dev will be refreshed from Prod, so the multitude of e-audit records that had been there will be reduced to that one that made it through to Prod.

    And then there's the question of ease of finding changes stored in the audit table and of going back to them. It would be nice if Maximo had code compare and merge features for autoscripts (and the other CIs that were mentioned) built on e-audit history.



    ------------------------------
    Blessings,
    Jason Uppenborn
    Sr. Technical Maximo Consultant
    Cohesive
    ------------------------------



  • 9.  RE: Automation Script source control

    Posted Mon March 20, 2023 09:25 AM
    Edited by System Admin Wed March 22, 2023 11:43 AM

    Easiest and least fancy approach will be audit enable AUTOSCRIPT table.

    Use rich text field to display historical changes.




    Original Message:
    Sent: Wed March 15, 2023 02:06 PM
    From: Teng Moua
    Subject: Automation Script source control

    Hi all,

    Seeing how others are managing their automation script source control.  We don't have a good process to see previous version or best way to keep version history with many developers in the system.  Any feedback would be great.

    -Teng



    ------------------------------
    Teng Moua
    ------------------------------


    #Maximo
    #AssetandFacilitiesManagement


  • 10.  RE: Automation Script source control

    Posted Mon March 20, 2023 01:37 PM

    Our team ( 4 developers) adopted the "Git model" as it described here : https://nvie.com/posts/a-successful-git-branching-model/

    We are using Subclipse ( for SVN repository) not git. But the model for managing the code is working fine for us.



    ------------------------------
    Galina Leonova
    ------------------------------