I have a question about Version control and multip...
# suitecommerce
a
I have a question about Version control and multiple development. Forgive my ignorance as my experience is limited. Our partner does our SCA Dev in Sandbox, we test then they deploy to production. If we have multiple development tasks running at the same time, they are unable to deploy changes individually. They advise we have to have a Change Freeze, sign off all pending Changes, and deploy all at once. (as some dev work touches the same file) Surely they can use GitHub (or similar) to use 'branch' development? I want to do changes myself, as well as them, so there must be a way to run concurrently development work and deploy change individually? Thanks
p
The problem developing for cloud applications like NetSuite, is that you don't get a simple, throw-away environment cloned from production to just develop your small change on, test, and approve, and forget forever. The problem doesn't reside on source control, but in having an isolated and controlled environment to develop and test on. Which is way simpler in let's say... Magento for example. --- That being said, It's definitely possible running different code branches in NS by having multiple domains in sandbox (if they develop using themes and extensions), and SSP Applications (if they modify the core, or the version is Kilimanjaro or older, this is needed too).
a
We are running 2016.1.6 Dev is done in Extensions, Themes and core code. We may edit the core code, and they may edit the same file. Both changes need to be 'merged' eventually, once both have been deployed.
p
you meant 2019.1.6 right? yes, it's definitely possible by using a combination of multiple development domains plus SSP Applications, and perhaps even Extension versions. It's definitely doable. It does have restrictions. For everything that is not SCA code, you have only ONE sandbox and website record to set things on. Setup Website configurations, SMT COntent, user events, Scriptable carts, changes to Custom Fields, to custom Records... all shared, for example
It's definitely more complex and constrained and more error prone than having a "standalone environment to develop a feature", which is you might find in other Website development environments.
This is what i can think of as of reasons on why your team advises to deploy parallel features in groups. Because at the end of the day you'll be always be testing exactly what production will be once the features are deployed. (I'm assuming this because i want to think these days everybody is familiar with developing in branches.) As for myself and the teams I've worked in... we normally take the risk, work in branches and in different domains/etc and well, 95% of the time it works perfect.
🙂 1