Refresh NetSuite sandbox from production (code only)
I realize that we can refresh out sandbox from production but we don't want to refresh the entire sandbox, instead we want to refresh NetSuite SuiteScript, NetSuite Forms & UI Objects.
NetSuite's proprietary infrastructure/code and challenge it brings
I resisted asking this question for several weeks thinking it was too basic but it doesn't appear that way. After working with NetSuite for a while it has become clear that the line between source code and data has become blurry and it's my opinion this is exactly what makes refreshing code challenging.
I've also learned that storing NetSuite code in version control software is next to impossible (for all code) and this leads me to believe that my desire to refresh code only might be impossible as well. I have to wonder how IT shops that are encumbered by SOX compliance issues are able to satisfy auditors when it comes to controlling and modifying the business logic.
The real question and reason for refreshing the sandbox code
My motivation for refreshing sandbox code is the fact that we are encountering unexpected behavior in our sandbox accounts with certain forms (invoice & estimate) where custom tax fields (Ava-Tax) mysteriously moved from the items tab to a tab that contains transaction body fields! The form appears to not have been updated by anyone in over a year and there were no packages installed in the sandbox that might have broken the form.
If I cannot refresh source code is there a way to determine how a NetSuite form became corrupted knowing that the NetSuite Form is stored in a proprietary way and with no apparent source code available? I understand most of the NetSuite code is JavaScript that runs on both the server and client and there are parts that are unavailable to anyone outside of NetSuite.
Any solutions or suggestions are welcome and appreciated.
It is not at all impossible to store NetSuite code in Source Control. We use git to track all of our NetSuite source, and we follow a process similar to gitflow. Our master branch is always kept in sync with Production. Anytime we push code to Production, that gets merged from its feature/fix branch up to master and tagged as a release. If we want to roll back, we just revert master back a commit and upload the whole project to the File Cabinet. Then, if we want to refresh a Sandbox to match Production, we simply checkout master and upload all of that to the Sandbox.
Sandboxes themselves are much more difficult to keep in sync with a single branch in source because we are constantly developing there on separate feature branches.
If you do not already have such a system in place, all you really need to do is download the zip of your SuiteScripts folder from the Production File Cabinet and upload that to your Sandbox.
This isn't source control, but you can use SuiteBundler to copy items between accounts. SuiteBundler allows you to choose from a lot of things like forms, scripts and custom records. Later you can uninstall the bundle or dissolve it into the account.
It's not so easy to explain in few words, here but: You can use a deployment account to get things work properly. So you continuosly work on dev accounts and use multiple bundle / bundle version for follow branches/Versions of customizations. You update bundle from dev to deploy account only when a version is stable and production envs always install / update bundle version from deploy (not from dev). Since bundles are versionable and infinite, you can use git + dev + deploy account for manage Cvs. For get a versionable version of a form just add &xml=t in url in any form. But this is read only
Related
I am doing this course on HTML, CSS, and Javascript for Web Developers on Coursera, as I am new to all this, and I have stumbled upon something that I think is very old information in the course, and not working anymore with the same tools as they have changed over time. So in this course we have the GitHub pages tool, which at that time could be used simply via the "deploy" button. Right now, the GitHub pages tool is disabled unless you create a branch, and it offers this GitHub Actions option under Build and Development, from where you can choose different workflows. By choosing any of them, you get the site deployed, but upon entering it, it gives 404 error. From my understanding, what's missing is the index.html file. How can you use the GitHub Actions tool to also have the index.html file and get rid of the error?
I have tried deploying from a branch, but I am missing valuable information on how to make that work.
Is it possible to create new branch directly from Issue which is posted on Github? We have project hosted on Github with many issues, it would be easy for us just to click one button in Issue web interface and create new branch for it to start developing.
This is not possible directly from the issue interface. I can try to provide you some workarounds and maybe start a debate why one would want this feature:
Creating branches directly on the web interface
After you've noticed that you need to start working on an issue you can just go to the repository main page (keyboard shortcut gc) and create a branch with the name you want:
Chrome extensions
If this is a must for you, you can create a chrome extension that augments the UI and creates a branch directly from the Issues WebUI using the GitHub API. There's a lot of open source extensions that augment the default WebUI.
Is it the most efficient way to start a new feature?
I think this changes from developer to developer, but having worked with GitHub for 7 years using Issues I've never felt the need for this feature because unless it's a one line change that doesn't require local testing or compilation, I still want to get down to my command line and IDE. If I have to do that, I still have to at least git fetch to get the branch I just created directly through the issue interface. If that's the case I've always preferred to just look at the issue and run git checkout -b branch-name, optionally with git push if my team needs to see the branch.
Then the issue name wouldn't normally translate to a branch name, at least I wouldn't want that. So that option to create a branch from an issue would probably need to spin out a prompt to allow me to name the branch what I wanted.
This is just my personal opinion and nothing else, hope it helps :)
GitHub finally added this feature request to their roadmap.
Summary
The branch is the first thing a developer creates when the start
working on a new issue. Creating that association makes it really easy
for someone to then follow the work happening and keep everything
connected as they take their idea to code.
Intended Outcome
We want to help developers get started on work faster and signal to
their team where to find the code changes related to an issue. It
should also be really easy to then follow development to the pull
request without the user needing to do additional work to link
everything together.
How will it work?
From the issue page, a user can quickly create a branch with an
auto-generated or custom name that becomes associated with the issue.
They can then fetch the branch and switch to it in their development
environment and further development changes (such as commits and pull
requests) are automatically associated with the issue.
https://github.com/isaacs/github/issues/1125
Nope. You can subscribe this issue.
You could accomplish this by creating a small script.
I'd start by leveraging the Issues Event webhook. This will fire a JSON payload every time an issue is opened. When the webhook fires, your script can then create a new branch using the Create a Reference API endpoint. Note: URL must be formatted as heads/branch, not just branch.
There is an app that automatically creates branches for issues. You can install it here for free: https://github.com/marketplace/actions/create-issue-branch
If you want to create the branches manually instead of automatically:
It does not enable you (directly) to click on create branch from the issue. Instead you would have to write a comment in the issue consisting of: /cib. If you do that, it automatically creates the branch from the issue.
Please note I have no affiliation with the app.
Recently I saw that Github finally added this feature to its Issues Panel.
All you have to do is navigate to an Issue on Github and scroll down to the following section:
I am working on a ModX website (mainly templates but also system settings, user management, etc) while a development website is already online with the customer starting to input the content.
I haven't found a practical solution to push my work online (layouts are stored in the database) without overriding the content input by the customer (in the database as well).
My present workflow consists of first replacing my local modx_site_content table with the one extracted from the online database, then push this hybrid database online. Not practicle, plus I am not sure user changes are confined to modx_site_content only.
There must be a better workflow though! How do you handle this?
I don't think it gets any easier than selecting the tables you need and exporting only those into the live environment. Assuming you only work on templating, the template, snippet & chunk tables are all you need to export.
We usually take a copy, develop, and merge only once when the new features are supposed to go live this minimizes this trouble. Also the client can continue normally until d-day.
If youre doing a lot of snippet work you could always just include an actual php file instead and work with your editor directly towards those files, connect them to git and what not.
If you project is not really big, you can store your chunks/resources, etc. in a separate files (there is and option called "Static Resource"), and then, manage your changes with git. Otherwise, you need to store user data in a separate table and deploy the whole database with Fabric, for example.
The problem i am trying to solve is where developers change files without going through the proper channels. The developer should be able to make the change himself but only after his work was approved, since the code is used in a lot of projects
I found this link that also describes my problem:
http://www.p4ideax.com/ideas/694/temporary-permissions
One way to do it is to have only the architects have access to the files and then granting the developer temporary access. Maybe the permission can be linked to a specific job in perforce. The only way i can see how to do that is by adding the files that the person should be able to change to a new field in the jobs template ( done by architect ). Then have a server app dynamically call p4 protect and manage the permissions table. Then when the job is closed the permission is revoked. The server app could be the bugtracker software.
Is there an easier way or even 3rd party software out there that can solve the problem?
I know that another way to solve it is to put these sensitive files in a branch and then only allow the architects permission to merge into this branch. This solution feels a bit heavy handed.
Any suggestions would be helpfull
This is something that could certainly be done with a pre-submit hook. There are examples at Perforce Depot.
My thinking would be to reject submits for files in that section of the depot that didn't have a job that was on the "approved list". You could create the approved list in a number of ways, although a simple one (if you're using Perforce globally) would be to put the job list into a file under repository control and then have that list be available only to the architects.
The pre-submit trigger would then basically need to:
- If the files being submitted aren't in the protected tree, let the submit happen
- Grab an r/o copy of the file from the depot
- Grab the job list from the submit
- grep the job against the list
- If the job is in the list, let the submit happen
- Reject the submit with an appropriate error message
I work on a software project which has a suite of source code that undergoes periodic change. The code is typically promoted to a production environment, and development continues in a development environment. Emergency hotfixes in production need to be backported to development. A third environment for testing may also exist from time to time. Many developers work on this code at the same time, often needing to make changes to the same individual file.
In short, a classic use-case for version control software. Unfortunately, we have a stone age IT department, and we do all our development in a stock Windows XP environment with absolutely no possibility of using any other software without approval - which never happens. We are lucky to have Winzip.
So what's the best way of managing the above workflow without any real tools? At the moment we are just editing files on a Windows shared drive, making ad-hoc working copies into folders with names like "James's Copy of X", doing backups with Winzip, and calling across the room, "is anybody working on this file at the moment?"
Thanks,
James
Edit: Some clarifications:
The irony is that the system is hardly locked down at all - I could download, install and configure TortoiseHg in about 7 minutes. But I need to do this by the book.
I am also actively pursuing getting version control software through official channels, but ETA for that is 6-9 months if ever, so I'm just trying to do the best I can with what I have now.
Finally, trust me, you will be reading about this project on TheDailyWTF one day, so please help me out with what I can do now rather than what management should have done last week.
Get source control. Talk to management, refuse to work, do whatever you can to get it in.
Bring in a netbook, install a SVN server and use that. Run Git off USB drives.
Really - anything.
It is not just an industry standard now - it is irresponsible of you and your management to continue working like this.
After notifying management and explaining that this is an issue, if they do nothing, just let the inevitable happen. Something that shouldn't have been promoted to production will be (regression, bug, new feature, whatever). When they come to blame you, explain how source control can help ensure that such things do not happen again. Perhaps they will listen then.
Ok, two actual options occur to me here.
First. You have Winzip, and you appear to have web access since you're posting on Stack Overflow. Assuming you have the ability to upload files (which isn't a given, since you're still using a generic StackOverflow avatar) you could find - or build - an externally-hosted service that'll allow you to upload a ZIP file via a web browser, unzip it, and then commit the unzipped contents to a Git or Subversion repository. Stick a secure web front end on it (Apache + mod-dav-svn) and you'll have the ability to browse, review and commit changes to individual files. You won't get the benefits of local SVN/GIT capabilities like merging, but you'll have centralized project history. There could even be a quite lucrative business model in this - selling web-based SCM to developers who are stuck on IE6 and WinXP and can't install anything.
Second: You find a junior/admin in your IT team who's just as frustrated as you are at the draconian restrictions being enforced, persuade them that you know what you're doing, and get them to 'accidentally' set up a local administrator account on your workstation. WinXP is sufficiently insecure out of the box that this shouldn't be too hard to make this look like an accident.
Copy and paste the files into a seperate folder and call that folder vers_x, or get the windows backup utility to save them each day, or another backup utility to do the same? though the first post is correct, strike till vers cont is implemented.
Get git. git init on the current source "repository". Install git on everyone's pc's.
Also, the strike idea is definitely not so bad in this case.