I am trying to figure out a better way to transfer bundles within our company and to multiple clients account. Which one will be the better way to install a bundle and later update it - Copy or Push? What are the limitations?
Copy is intended for versioning, deprecation and release testing.
You can think about copy as Forking a Project.
When coping a bundle, it will get a new bundle number and will appear on the bundle list.
If you want to move the bundle to client accounts, you have to install/push it on their accounts, never copy.
Related
I'm evaluating GitHub as a way to keep under version control and share some excel files containing basically financial models.
The issue I'm facing is this one: I need to share the Release artifacts (a bunch of xlsx files) with people outside GitHub, so I'd like to include the version number in the filename to be sure that, even when the files will be further shared by business people through email or other non-GitHub means, that information won't be lost.
Is there a way to rename the artifacts automatically? GitHub Actions seemed to be the right way to address this thing, but unfortunately they're still unavailable on the Enterprise Server my company is using (v 2.19.13, I don't have any administrative access to it, btw), and adding some CI toolchain just to rename some files is probably too much.
Thank you in advance for any response!
Michele
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
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 have an application and it is currently using one of the PullToRefresh libraries off of gitub. I've forked that repo, made some changes to better suit my app. I am responsible to give my customer the code for my application, so this would include the library. What is the recommended way to include it with my application source code (Using SVN for the android app itself).
I imagine at this point, you've long resolved your particular issue. For future generations, then:
If you're handing the user a zip with a snapshot of the source, include the library source in a subdirectory. What I have also done to good effect is to build a release bundle archive, which contains all of the different bits needed both binaries and sources.
If you're handing over source code repositories, again you can zip up each repository into a bundle you can hand over. It's probably worthwhile documenting the upstream for each bit of the project, so the customer can update your fork if they need to.
The situation:
I have a basic app with some central functionality.
My clients (potentially many dozens) all want their own customized apps in the app store.
The problem
If I have dozens of apps in the app store and I want to change some of the core functionality, I would have to update each file in the corresponding project, compile, go through iTunes Connect, upload etc. Every small change could potentially take days of mindless work.
The question
Is there a way I can use a versioning system like git to administer the parts of my code with the core functionality separately, so that all projects are updated automatically when I commit a change to the core files?
Is there any other way to make this process easier to manage?
Typically if you have some core functionality that you need to reuse in iOS you'll either create a static library that you can include in your other projects or (if the core functionality includes things like assets which can't be included in a static library) you'll have a sub-project. In both cases, though, you'll want to make sure each of your app projects has a target dependency with your core functionality project so it is always rebuilt with the latest changes.
Create a MundiCoreFramework xcode project that has all your core functionality and which compiles without having to reference client-specific code
Create a git repo for this core framework project
In each of your app projects that use this core functionality, add the MundiCoreFramework as a git submodule and add it as a subproject to the app project.
Whenever you update the core framework you can issues git sumodule update for each app and recompile.
I'm not real familiar with the Xcode "target" structure, so that may in fact be a better approach. But you can definitely use git for this.
Probably you want a "master" branch where all the universal stuff lives, then a branch for each "customized" version of the app.
When there are changes in the master, you'll merge those changes through each of the custom branches. Then from each branch, you'll build a product to submit to the store.
In each branch, you'll separately set the app id, whatever art and text changes are needed from one version to the next, whatever key setup is appropriate to this version, etc. All those settings can stay local to the custom version branch.
This is a perfectly valid workflow in git. It's not how most people use it, but that's because most people are headed to ONE production product, not many.
Another option might be using git submodules to organize common code, and then have each individual project simply add your common code as a submodule.
You can use Target to customize the app for each client, this would mean that you could keep one code base and have multiple apps with the same code base.
This will not solve the updating the app in the appstore part, which you would still have to do by hand as var as I'm aware of.