Maximo is an IBM tool.
You use the maximo Migration Manager set of applications to promote product configuration content from one product environment to another, such as from development to test, and to production.Can creating packages in the migration manager and promoting them from one environment to another be automated somehow outside of the tool, so say something like a script that can allow to login to the maximo migration manager and then allow to perform the manual steps.
https://www.ibm.com/support/knowledgecenter/SSLKT6_7.6.1/com.ibm.mbs.doc/gp_migmgr/c_ctr_mig_mgr_over.html
One option would be to write an automation script to create the migration manager packages and deploy them to the other environments using the psdi.dm Java package:
https://developer.ibm.com/static/site-id/155/maximodev/7609/maximocore/businessobjects/psdi/dm/DMPackageDef.html
You could then potentially trigger execution of the automation script from outside of the system with an HTTP request:
Run an automation script via a URL
Alternatively (and separate to Migration Manager) you could automate generation of dbc scripts for product config. changes:
https://developer.ibm.com/static/site-id/155/maximodev/dbcguide/
https://github.com/ibm-maximo-dev/maximo-scripting/blob/master/samples/AS11_importExportScripts.md
Related
We are improving our CI/CD process and we understand that we need to use GitHub (or similar) for a better version control..
We would like to integrate SuiteCloud with Github to upload ALL our objects in order to track an monitor any changes. Also, we are planning to use branches to deploy code in our instances. Ex: Master = Production. Dev Branch = Sandbox1, Homologation = Sandbox2.
So... is possible to do it? And how? Any experiences to be shared?
Since SDF manipulates text (xml) files their management is no different than for any other git based CI/CD process.
Netsuite has java and node based CLI tools that can be incorporated in Git Actions for automated deployments.
You'll have some fun if you want to automate testing as that can be problematic with any live database.
I am new to Azure DevOps and trying to create my first Azure pipeline. I have a ASP.NET MVC project and there are a few NuGet packages that need to be restored before the MSBuild step.
Unfortunately, the NuGet restore is failing with the following error:
The pipeline is not valid. Job Job_1: Step 'NuGetCommand' references
task 'NuGetCommand' at version '2.194.0' contains an execution handler
that relies on NodeJS version '6' which is restricted by your
administrator.
NodeJS 6 came disabled out of the box so we are not going to enable it.
My Questions:
Is there an alternative to NuGet restore that does not use NodeJS?
Is there a way to update the NodeJS6 to a higher version?
update 23-Nov-2021
I have found a work around for the time being. I am using a custom PowerShell script to restore NuGet Packages and build Visual Studio project
$msBuildExe = 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\MSBuild.exe'
Write-Host "Restoring NuGet packages" -foregroundcolor green
& "$($msBuildExe)" "$($path)" /p:Configuration=Release /p:platform=x86 /t:restore
Note: $path here is the path to my .csproj file
Apparently, other people are also getting the same issue and it is just a matter of time that the task is updated by the OpenSource community.
Here are some similar issues being faced in other tasks as well:
https://github.com/microsoft/azure-pipelines-tasks/issues/15526
https://github.com/microsoft/azure-pipelines-tasks/issues/15511
https://github.com/microsoft/azure-pipelines-tasks/issues/15516
https://github.com/microsoft/azure-pipelines-tasks/issues/15525
It's AzureDevOps' NuGetCommand task that uses NodeJS, not NuGet itself. Therefore, you can find a way to restore without using Azure DevOps' NuGetCommand task.
Idea 1: use DotnetCoreCli task instead. However, this probably won't work for you since you said your project is ASP.NET MVC, rather than ASP.NET Core. Also, it also appears to need NodeJS to run.
Idea 2: Use MSBuild restore. You can test on your local machine whether or not this works by clearing your global packages folder, or temporarily configuring NuGet to use a different path, and then running msbuild -t:restore My.sln from a Developer PowerShell For Visual Studio prompt. If your project uses packages.config, rather than PackageReference, you'll need to also pass -p:RestorePackagesConfig=true (although maybe this is currently broken). I'm not an expert on Azure Pipelines tasks, so I don't know what it means that this task defines both PowerShell and Node execution entry points, but maybe it means it will work even if your CI agent doesn't allow NodeJS.
Idea 3: Don't use any of the built-in tasks, just use - script: or - task: PowerShell#2, but even that is a little questionable whether it'll work since even the powershell task defines a Node execution entry point. I'm guessing it will work, but I don't have access to a CI agent where NodeJS is forbidden, so I couldn't test even if I wanted to. Anyway, if this works, then you can run MSBuild yourself (but it might also be your responsibility to find msbuild.exe if it's not on the path). Or you can download nuget.exe yourself and execute it in your script. The point is, if you can get Azure Pipeline's script task working, you can run any script and do everything you need yourself.
Idea 4: Use Microsoft Hosted agents. They have documented all the software they pre-install on the machines, which includes Node JS. Downside is that once you exceed the free quota it costs money, and I've worked for companies where it's easier to get money to buy hardware once-off, and pretend that maintenance of the server is free, even though it reduces team productivity, rather than pay for a monthly service. So, I'll totally understand if this is not an option for you.
Idea 5: Talk to whoever maintains your CI agents and convince them to allow & install NodeJS. It's clearly a fundamental part of Azure Pipelines. The tasks are open source on github, and you can see that pretty much all of them use NodeJS to orchestrate whatever work it does. Frankly, I thought the agent software itself was a NodeJS application, so I'm surprised that it runs without NodeJS.
I am using a terraform enterprise instance to manage three workspaces that represent infrastructure for the various environments of an application (development, pre-prod and prod have isolated infrastructure). The workspaces themselves are configured using a tfe_workspace resource.
I'm using a VCS-driven flow to create the configuration versions as I need speculative plan runs on PRs and I'm fine with automatic runs being created for master. I'm using the API to determine when to apply runs so that the staging environment can be applied and have automated tests run against it before the production workspace run is applied.
This works fairly well, except that I have been unable to use the api to apply non-default-branch configuration versions (i.e. from a PR) to the development workspace. Any run I create using a configuration version that was not created from the master branch does creates a plan-only run.
Is there a way via the Terraform Enterprise API to apply a PR configuration version?
I was able to work around this by not reusing the PR's configuration version, and creating one of my own via the API instead.
We are looking at removing developers from production and want a simple kind of deployment management tool. One suggestion that some members are using with SalesForce is Jenkins. I have never used Jenkins or any kind of deployment tool before. I normally just copied my code from IDE and updated the file in the SuiteScript file cabinet.
Does Jenkins work for NetSuite? Or what do you recommend for this purpose?
We are planning to use Bit Bucket (which runs Git in the background) as our version control in case that matters.
Thank you for any help
IMO the greatest challenge in integrating with any CI environment(be it Jenkins or any other) is the fact that you can move code files from one system to another using code/APIs but, NOT things like scripts, custom records, fields its deployments , etc. for which you need a bundling process and hence, manual intervention.
NetSuite in recent Suiteworld 2015 said that its coming up "Change Management" which would allow you to put everything that is part of your app to version control system such as git. Please see SuiteAnswer Id 42387, when this feature is rolled out, you can integrate with your CI tool to automatically copy/deploy your app details to an another NetSuite account and run your tests there and accordingly pass/fail your build.
Why do you want to remove developers from Production? This will severely hamper their ability to create solutions for your NetSuite account and will create a ton of overhead for them.
If you must have them out of Production, then probably your "best" option would be to have them build their solutions in Sandbox and then use SuiteBundles for deployment to Production. A Production Admin would need to update the appropriate Bundle(s) for all Production migrations.
NetSuite has also built a SuiteCloud IDE plugin for Eclipse which allows uploading and downloading files (no copy-paste necessary), so if you're not using that I would recommend it.
We are using Jenkins for our own internal automated testing, but not for deployment into NetSuite. I do not know if someone has already built a NetSuite plugin for Jenkins; it is likely you would have to build your own file upload mechanism using the NetSuite Web Services SOAP API, but that would still only allow deployment of source files. Developers will most likely also need to be creating and updating custom records, fields, lists as well as Script records and Script Deployment records, which you will not be able to do through Jenkins or any other tool that I know of.
We are running CRM in an enterprise style environment, with 4 environments that changes need to propagate through before entering production. We are also dealing with a very large dynamic dataset and complex logic implemented in SQL server working from this dataset, along side the CRM components.
Our environments are as follows:
Development
Test
Staging
Production
To facilitate development, testing, etc we restore our dataset and CRM from Production back to the various environments as needed, in Development we restore very frequently (usually nightly).
One of the challenges we have encountered with this is that when restoring the CRM tennant automatically using the powershell tools, we need an accurate UserMap XML file available which contains all the users existing in our production environment. Currently whenever a new user is added to production we our automated restore fails and we have to manually update the file.
In looking to automate file creation, I was unable to find the answer to the following question: Does the UserMap.xml file need to also include disabled users?
To resolve this we produced a new UserMap.xml file from the production environment and manually checked to confirm that in face Disabled users ARE included in the UserMap.xml file.