https://netsuiteprofessionals.com logo
Join Slack
Powered by
Anyone got any interesting workflows they’re using...
# suitescript
c
Anyone got any interesting workflows they’re using to manage teams of devs that often work on the same scripts, across different environments, at the same time?
a
I'm not sure how interesting it is ... but git and branching helps a lot... and devs that actually freaking commit and push without having to be beaten over the head helps too
c
This team have a well worn branch development process.
a
... then I'm not sure what the issue you're trying to solve is?
c
This cannot be the pinnacle of what is possible though
Multiple issues: having to always merge environment code back to the IDE meaning you have to do a selective commit/push
Risk of overworking someone else’s test code
Having a separate repo clone for every env (prod, sb1, sb2, sb3, sb4 etc)
a
... a seperate REPO per environment?
e
Oh yikes, a separate repo for every env sounds like a nightmare
a
!!!
c
Trying to introduce salto which doesn’t appear to be making things any better
No, not separate
I mean 4 clones
One master
a
branches?
c
Which means 5 master clones (all the same).
Yes, shit loads of branches
One per feature
One per fix
a
right but should have them feed into each other
so you have 1 main, which is prod
then you have a branch per ENV
c
Yeah, that’s easy
A branch per env was shot down
a
and then the feature branches should be off of those env branches and merged back in when they're commited
c
Can’t persuade them on that
a
... shot down by... what? i don't
c
How would you manage pushing code that’s not on the env branch?
And the merge issues
a
merge into what though? you're merged all the feature branches into main? even tough they're all deved in different envs?
c
It’s hard to articulate from my phone
👍 1
a
its too early for this on a Saturday... if this were me I'd quit... you're deccision makers are aparently insane
c
The team push testing code from their branch to the env
Which means overwrites
So you have to compare first then pull their changes back into your code before pushing into the env
This code doesn’t live in master yet
Yeah, we’re in a multi-dev, fast moving, and complex environment
a
seriously though this is a bigger conversation, probably need to provide a lot more details about the current process and why you got where you are
c
Git and branches is nowhere near the answer lol
👍 1
a
this is very different from we have no process and out devs keeps scewing each other up 🙂
c
I reckon this is in the top few percent of sophisticated netsuite clients.
It’s almost real software engineering :-)
😂 2
🤭 1
a
Both Eric and I worked at a place with a similar amount of process / sophistication previously
c
I was hoping salto would save me
Magic bullet :-)
a
idk anything about salto, but I've heard good things, I'm sure eric can provide deets
c
Jury is out on salto, we are evaluating it.
I’ve been ordered to use vscode - this dictate will likely push me over the edge lol
👀 1
a
i will say given what you've said already this is going to be as much about a hearts and minds mission as it as a technical magic bullet.. process changes only work if ppl adopt them, you need the buy in at all levels and you need to not tank morale at the same time 🙂
c
Would be great to collaborate on a miro board (or something) to come up with a reference process for complex suitescript teams
I reckon at least 1% of NS customers would find it useful :)
a
< 1% tbh but yeah
e
I don't have any context for your team or the reasoning behind the decision-making, but some general thoughts: • I use a 
main
branch to represent Production-ready code and then a branch per feature/fix/task/whatever • For major, complex features, I introduce a short-lived 
release
branch to consolidate the features for that release • I don't use environment-specific branches or a 
dev
branch • If a team of developers is regularly working in the same files and stepping on each other, that feels like both a code smell and an operational smell to me. The code has not been decomposed into separate modules enough, and the resource allocation has not spread the developers out across features/fixes. • "We move fast" always raises my eyebrow.
c
We’re not moving too fast for process
I just don’t like the process
😂 1
I was ok until I was ordered to change my workflow to match the rest of the team
😬 1
And now I’m looking outwards to see what other complex users are doing
There’s one militant guy that runs the show and he can’t tolerate you using a different IDE
lolol 1
e
The place Anthony mentioned, we had up to 7? developers working on the same repository using the branching structure I described (
main
plus 
feature/*
), and collisions were pretty rare because we: • spread out our developers across different areas of the code, and • broke down our code into small-ish modules The collisions we did have were almost always in these large catch-all utility modules we had that desperately needed refactoring
💯 2
c
A refactor towards smaller scripts would be welcome but probably a tremendous engineering effort and $$$
e
The collisions are also $$$
c
The script catalogue is so long it takes sheets a while to load already..
a
what's the reason behind mandating a specific IDE? that doesn't make a lot of sense to me.. everyone following the same process does make sense... forcing everyone to use a specific IDE just sounds like a way to piss people off
e
Personally I'm not sure how anyone would know or why anyone would care what IDE the code was written in, but I have also found this is not an uncommon stance in the dev world
🤷‍♂️ 1
a
having a recommended IDE, and a howto guide and "official" support for that is fine... but if someone wants to use something else its on them to be able to follow the process using their IDE... and honestly I don't know what process you could have that any IDE couldn't be used effectively in it?
☝🏻 1
☝️ 1
b
oppression: one repository per environment, with the other repositories forked from the production one, one main branch that is used for deployment and as many feature branches as you want. Anytime anyone want to deploy, the feature branch must be merged to the deployment one
💯 1
c
One vocal and militant dev
a
you started this by talking about a technical problem, but the more you explain the more it sounds like a personnel problem
c
@battk how do you handle having to push to a common branch before deploying?
That would mean your branch is full of code not ready for master
a
you have massive horrible merge conflict resolution meetings with the entire dev team for every merge... and its horrible
c
I guess you could selective merge to master rather than merging the entire branch
a
I've worked in a place that did that... its was painful... but honestly it did mostly work
b
if your code isnt ready for master, it isnt ready for deployment
c
How can I test without deploy?
a
production deployment, I assume?
c
I don’t disagree with you in principle - throwing the teams objections that I can’t overcome
b
i mean, it sounds like you have multiple environments, so its not actually being deployed to production
c
Prod is the least of my worries
😂 1
Master points to prod, that’s the easy part :)
b
but one of your primary goals is to actually know whats in the account without looking, and you cant do that if you allow people to have multiple versions of the same file at the same time
c
We’re supposed to always compare the account and merge before uploading
That way we combine multiple branches on the env but not in git
a
I think the real solution is probably refactoring and making the code base more modular so that there isn't all these files that are commonly modified by different people all the time
c
Then when I pass my test, I can roll out the env specific code from someone else and only commit/push mine
Then merge to master
a
but that's its own initiative, but the additional work is probably going to pay for itself in <6 mos
b
id like to add that oppression is not actually oppressive if there are no conflicts
but if there are, it ensures sanity while merging
c
There’s the occasionally overwriting of other people’s code in the dev envs
Then Mr m will jump on a call and blame the web storm users
Because 4 clones of master, one for each VSCode workspace, is the panacea apparently
Nobody is really seeing the need for process improvement here, just me, and only since being ordered to change IDE and match everyone else’s local workflows.
a
update your resume 😛
👏 1
c
It’s more likely I’ll drop this client than continue to advocate for sanity
a
I will say this... it might be useful to remove the emotion and the personality clashes from the situation - reset your relationship with mr. militant and work just with him on coming up with a solution that works for everyone... cos right now it sounds like even if there was some magic bullet if it means you get to keep using webstorm and that's gonna be an issue for him then he's going to make sure that are still issues
take a breath, engage your empathy and try to really understand where he's coming from and why... you might actually learn something from him that will make the rest of the issues make sense instead of just being frustrating and thinking things are insane
c
Yeah, I’ve taken the high EQ road for a few months now but it’s not getting any better.
I’m keen to work it out because it’s an interesting use case but I’m getting very tired of whole team PR reviews everyday where we are only allowed to share screen with VSCode (not even allowed to show diffs on GitHub.com without Mr M getting upset.
a
you do PR reviews online? I found it best to do them asynchronously with comments inside the PRs
c
Yeah, I’m a former software engineer before working at NetSuite, so I’m well versed in industry standard practice
But at $client, code review is a done in VSCode and it’s a team sport.
These aren’t really engineering issues though, just people issues.
💯 1
e
Sounds pretty frustrating; sorry yall are going through that.
c
Thanks for the space to rant, have a good weekend :-)
a
yeah good luck 😞
a
The approach @battk first mentioned is my go to, you solve the file overwrite thing all-together only with good branching strategy. • You have something like 
env/SB2
• Dev 1 working on 
feature/fix1
• Dev 2 working on 
feature/fix2
• .... Devs 
ALWAYS
merge to 
env/SB2
before they upload files. All your problems solved.
c
@alien4u how’re you promoting code to a higher env from the sb2 branch?
a
@Craig Out env/SB2 what passed QA/UAT is then individually merged into the higher branch… You don’t merge env/SB2 into master because env/SB2 represents your in-progress work.
That mean in the example above that once feature/fix2 passes QA/UAT then you merge that one into master for example(production) but you don’t merge feature/fix1…
c
How do you make the entire SB2 branch pass test? Isnt there constant commits that would mean you’re promoting code that isn’t ready?
a
You don’t, what passes QA are the individual features branches.
c
This is the kind of thing I wanted to implement but was met with tremendous resistance
Now salto are trying to sell their tools to us, feels like a good opportunity to try and get this in.
a
Resistance to change would be there all the time it is very common, you need to pitch your idea very carefully and very well crafted. Once I’m back at my desk I will share a couple of branching diagrams I created in the past, you can use those as a baseline of some sort.
c
How do you test only one feature branch at a time? Wouldn’t you need to merge the feature branches when deploying if you have multiple devs working in the same script at the same time?
This is quite a mature dev squad (one of many) so change is tough when they believe they’ve iterated to the best workflow possible already. To be fair to them, it’s one of the most mature NS teams I’ve ever seen.
b
if you have multiple people working on the script at the same time, then they will overwrite each others changes all the time. forcing a merge to the main branch forces the changes to be compatible with each other, or at the very least detects conflicts early
c
You might call that - continuous integration
But then the team want to cherry pick what gets promoted as one change is tested ready before another despite the merged code both being in SB1
b
its going to happen sooner or later
the later changes will have to be merged into production at some time
if its trivial and there are no conflicts, it wont matter
if there are, you catch them early to not screw yourselves
c
It matters because it changes functionality or it not just not tested enough
So shouldn’t promote to SB2
I thought about working in sprints and having a release window for a sprints worth of changes, this means we never have to cherry-pick. That was shot down though
The only other credible option is continuous integration
Also shot down
b
if for some reason you really want to do one and not the other, you can revert. which tends to be really annoying
c
The way it works now is: 1. Create feature branch (fb) 2. make code changes in fb 3. Compare fb with sb1 (sb1 will likely have someone else’s test code deployed that is in their own feature branch (fb2)). 4. Merge changes from sb1 back into fb workspace in the IDE (do not commit) 5. Deploy merged fb and sb1 code into sb1 6. Test my feature 7. Test passes 8. Rollback IDE workspace to remove merged SB1 code 9. Commit and push my tested code to fb 10. Compare fb with sb2, 11. go through same process as sb1 but on sb2 12. stakeholder tests on sb2 and is happy 13. Create PR to merge with master ready for prod release.
Also, I’m told i have to use VSCode and I must clone the repo 5 times and maintain 5 vscode workspaces. (sb1 - 4 and prod). I’d prefer to have one git clone and manage out of a single WebStorm project using the SDF plugin to manage comparing and deploying to NS. I’m told the risk of WebStorm “doing something not aligned with our flow” isn’t acceptable.
15 years of software engineering, architecture, and some consulting and all of a sudden a team want to control what tools I use on my own desktop….
b
between steps 3 and 8 is where only one person can be working in the account at the same time
so if you can figure out how to enforce that, its sane, else not
c
We enforce 3 - 8
Always compare and merge before deploy
Works most of the time due to developer discipline
b
if someone commits something while you are testing your own code, it can make the test pass while in fact its fails
it can even do the reverse
c
I’ve only wiped out someone else’s SB1 code once (takes seconds to redeploy from a branch) and was told I have to stop using WS and comply with the “standard” workflow using vscode
b
onto your actual problem, im more on the team conformity, all team members use the same tool
c
It shouldn’t matter
I can git push from the terminal, vscode, or WS. It’s all the same
Same with comparing files in NS and deploying.
All on Mac so we even have the same line breaks etc.
b
if they can tell you are using tool a while everyone else uses tool b, they have already noticed a difference
c
They can tell because after 2 months I shared my screen
b
and all problems will now be blamed on a, even if it doesnt matter
c
And Mr M did not like looking at his PR in webstorm
Correct / everything is now blamed on webstorm
He wouldn’t have know had i not have shown him
b
it doesnt really matter if there isnt a difference, especially if you cant convince otherwise
c
Nobody cares except the loudest voice. So it becomes a people problem, not a tech problem.
A different instance of the IDE (vscode) for each of the five NS environments is just starting to annoy me. 5 repo clones too. I spend more time switching between VSC instances and constantly managing 5 clones than anything else. I'll look for a way to manage the repo and deployments form a single VSC instance and single got clone.. that is breaking the teams rules though..
a
I’m saying this with the utmost respect for you and your dev team, but keeping 5 clones of one branch screams operations/structure problems to say at least(as @erictgrubaugh politely metioned). It also screams poor branching/git knowledge or branching design. (personal opinion), plus: WebStorm “may” do something not aligned with our flow?(WTH?)…
c
Yes, I completely agree with you @alien4u
I've mentioned this twice since being forced to do the same and I keep getting comparisons with SVN thrown at me. It's a losing battle. I wouldn't be here soliciting opinions if I thought this was good.
I'll just go with the flow for now then not renew the contract when I'm done in a couple of months. You can't always win.
e
^ FWIW if I were in your position as you've described it, I'd probably look to take this same option, and if my contract had an early exit clause, I'd probably be looking to exercise it
Simply sounds not worth it, but I have a pretty low tolerance for this sort of behavior
💯 1
s
I've been looking at Salto as well, and I'm thinking it may indeed help with managing all promotions from one NS environment to another; it just won't be able to help much with the environment(s) initial development is performed on.
c
For those looking at Salto, I've just spent a few days using it and it's 100% a must have for large and sophisticated NetSuite accounts where you have multiple devs, or even multiple dev teams. It's a real attempt to inject some standard engineering release practices into NetSuite. It's still tricky if multiple devs are working on the same scripts, at the same time. I don't think any tooling will handle that for you though, that's just about discipline and experience,
❤️ 1
a
<this post sponsored by Salto> 😂
seriously, I should probably look into them a little more, they do seem like the real deal
c
Use my referral link 😂
😂 1
e
if multiple devs are working on the same scripts, at the same time
IMO this is a code smell and a planning smell, not a tooling smell
a
yeah that just screams modularize this code and use libraries
c
There's a few 'centralised' modules that get touched all the time
i.e there's a shared file full of pseudo ENUMS which always gets updated
so constant conflicts there
Each major transaction type is modelled as a class, so any changes in those tend to clash.
I can appreciate what they've done, trying to make reusable objects so you don't end up with the same code pasted all over the place.
a
As a class, it is nice... OOP in NetSuite I love it... lol
a
this sounds like someone knew more about OOP / Java than they did about JS/NetSuite and decided all problems are nails and OOP is a hammer
c
Yea, the engineering lead came from enterprise style .NET
the codebase looks like classic .NET
a
🎉
can i quit this job on your behalf? 😛
c
haha
Few months left on the contract
🙏 1
⏱️ 1
s
Actually this sounds similar to NFT - though NFT is very much TypeScript native but borrows heavily from JS and other language best practices 🙂
c
Yeah, I asked why they don’t just use NFT.
A case of the “it wasn’t built here” syndrome.
s
ugh
c
Because clearly it’s better to roll your own buggy untested implementation :-)
s
NIH syndrome will get you fired in modern organizations.
I was just chatting today with a colleague about one example of this that almost cost Boeing $1M by their 'smart guys' writing their own String class (a C++ contract gig I was on many years ago) rather than using the standard library.
8 Views
Open in Slack
PreviousNext
Powered by