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.
Related
I was hoping to get some feedback on using Azure Pipelines and what the best practices are for my situation.
We have recently migrated from TFS 2017 and we are in the process of re-writing all our pipelines. We were using builds and releases prior to the upgrade in the legacy build tasks. We would like to setup more useful YAML pipelines.
Let me set the stage with what we currently have
10+ microservices
10 individual builds that trigger from a folder in the repo for each one
10 releases that get created on successful build
3 environments per release (Dev, QA, UAT)
So in summary... a build of a single microservice triggers off of a commit to a folder in the branch. The successful build then triggers a release to Dev. Dev completes and a user go go start a QA build by clicking the release.
In the new Azure Pipeline world... what would be the best approach to doing this model.
We would like to have all the builds happen in a single pipeline (each stage would be a microservice?)
How do we trigger only on a commit to that folder?
What would the CD look like? Should it be in the same pipeline and be a new stage?
How can we easily just add environments without having to just keep copy/pasting all the code for each environment? Ideally i would like to just be able to add a variable and a new environment can be deployed to
I am open to any suggestions here. I am ok if I am way off here, I am looking for the best practices and best approach to this.
TIA
I am learning azure data factory and would really like to do its development in Visual studio environment. I have VS 2019 installed on my machine and I don't see an option to develop ADF in it.
Is there any version of VS that ADF can be developed in or we are right now stuck with developing it in web UI for the time?
I know BI development tools needed additional plug in to VS environment to work. Does ADF need something similar to that too.
If not, how can we back up our work done in web ADF. Is there an option to link it somehow with the azure repo or GIT?
Starting with ADF V2, development is really intended to be done completely in the web interface. I had the same question as you at the time, but now the web tools are quite good and I don't give it a second thought. While I'm sure there are other options for developing and deploying the ARM templates, do yourself a favor and use the web UI.
By default, Data Factory only saves code changes on "Publish". An optional configuration allows source control via Git integration. You can use either either Azure DevOps or Github. I highly recommend this approach, even if you only ever work in the main branch (fine for lone developers, a bad idea for collaboration). In this case, Publish takes the current state of the main branch and surfaces your artifacts to the ADF service. That means you will still need to Publish for your changes to be live.
NOTE: Git integration is also supported in Azure Synapse, where it has tremendous value for collaboration across a wide variety of artifact types.
Currently I am working in a project in which we are using Gitlab for repository management. I am the owner of project so I want to automate the code checkin validation on daily basis . my question is , Is there any option so that, I can configure the daily check(whether developer pushed there code or not) and send the notification to developers?
There is no build in functionality for this.
As this is a reasonable feature you should follow the feature request workflow of Gitlab and open an issue for that. https://gitlab.com/gitlab-org/gitlab-ce
But keep in mind that such feature will be probably only available for the EE version.
As alternative you can use the API of Gitlab to extract the commits of a project. https://docs.gitlab.com/ce/api/commits.html
Then process the date diffs using a e.g. python script and send an email or post on a Mattermost channel using their API. https://api.mattermost.com/
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.
I am currently thinking of a way to nicely structure my web project with mercurial. I was thinking of having two branches default (for development & testing) and release (the finished code which gets published). I would develop and test on the default branch until I have a stable application running. Then I would merge into the release branch. When I push the code to my central repository (on the server where my web application lives) I would want the code to be automatically published.
Is this the right way to go and if yes can this automatic publishing of the release branch be achieved with hooks?
Have you considered the git-flow branching model? I would recommend it and also hgflow by yujiewu. The latter is an implementation of the git-flow idea for mercurial.
Instead of a "release" branch, you should name it 'stable' as several projects do.
Do you use Continuous integration yet? Maybe, you should. In Jenkins, you could create a post-build step to publish the release if everything went well. It's better than a changegroup hook.