This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # ask-the-speaker-more (10)
- # ask-the-speaker-plenary (1086)
- # ask-the-speaker-track-1 (268)
- # ask-the-speaker-track-2 (106)
- # ask-the-speaker-track-3 (338)
- # ask-the-speaker-track-4 (216)
- # birds-of-a-feather (9)
- # bof-arch-engineering-ops (2)
- # bof-covid-19-lessons (3)
- # bof-leadership-culture-learning (1)
- # bof-sec-audit-compliance-grc (12)
- # demos (13)
- # faq (4)
- # games (76)
- # games-self-tracker (14)
- # gather (36)
- # general (424)
- # happy-hour (91)
- # hiring (26)
- # lean-coffee (16)
- # project-to-product (2)
- # psychological-safety (2)
- # summit-help (99)
- # xpo-anchore-devsecops (12)
- # xpo-cloudbees (1)
- # xpo-copado (33)
- # xpo-gitlab-all-in-one-devsecops (15)
- # xpo-harness (1)
- # xpo-hcl-software-devops (20)
- # xpo-ibm (5)
- # xpo-itrevolution (18)
- # xpo-launchdarkly (15)
- # xpo-mirantis-devops (5)
- # xpo-pagerduty (9)
- # xpo-redgatesoftware-compliant-database-devops (1)
- # xpo-snyk (3)
- # xpo-sonatype (5)
- # xpo-split (3)
- # xpo-synopsys (8)
- # xpo-tasktop (9)
- # xpo-tricentis (2)
Welcoming @ashley.noble in a couple of minutes, joining us from Australia today!
I see 82 watching live! Post comments and questions here for @ashley.noble
I didn't quite catch there - are the templates runnable applications or examples to get started
Do each of the templates encapsulate the whole stack or are they also available by component e.g. logging
They seemed to be language/tech stack based...do the templates also include the data layer
@matthew.cobby, so if you create a C# WebApi pipeline, when it finishes creating, you have an endpoint that you can hit that is deployed into QA.
@ashley.noble Is this a "build to attract teams in model" or "force teams to use model"?
Central build system has access across all cloud subscriptions? What was the security split? Non/Prod?
@gus.paul they provide some basic abstractions like repository pattern as a guide for teams, but not the actual DB stack, as teams generally have a preference for how they want to talk to there dbs
Forgot to use threads 🙂 What do I mean? You create a pipeline that is compliant with AutoMate. Day 1 - all is good. Then over time, teams make a change here, make a change there. Somebody hire a DevOps contractor that goes wild and changes it all. Is that kept in line with a Pipeline of Pipelines approach or through a software clean room (Capital One) governance model or maybe it is just natural evolution
@matthew.cobby, sorry missed the thread. (great to have another Oz person here as well 🙂 ). So the pipelines themselves don't drift, and when we provide big updates they "re-execute" their pipelines and that makes sure that they still work the same way. There is drift in the code, and perhaps the frameworks they're using for development, but since the pipelines "just work" for them, they don't usually touch them and so very little drift.
@tim.wyatt Build to attract... if it's not easier, we're not winning. Teams can do it themselves, but we cut their time down dramatically
It's probably about how you manage template changes. If devs start out with an old template and you change the teamplate afterwards, you probably want to keep the artifacts created from the template up to date as well. Is this the point where the script that you mentioned comes into play?
Which security scanning tools are you using? We've not had a lot of success in that space
@gus.paul Coverity (static code), BlackDuckHub (OpenSource), Twistlock (Container)
Did Teams generally like the push for standardization or was there resistance?
@manzi.g yes, this is for internal developers, of which we've got quite a few
Interesting point on the "contributions" Jono Bacon would talk about building communities
we started to build a dashboard who contributed to it
and so drove behaviour to show this in newsletters and events
We have similar league table of inner source contributors...it definitely works
@robert.ruzitschka most people liked it and went with the flow. 5% wanted to swim up stream, and I was inclined to let them and spend time helping the teams that wanted help... generally the 5% ended up sinking and came back later on.
Hi @ashley.noble! Did you use the Google 4 Keys to build this dashboard?
@tim.wyatt sometimes we gave out internal awards, but mostly they just got their "feature" in quicker.
That is a powerful motivator - we have an Inner Source programme to enable those changes into the platform in a formal way
We find conversations work well. They do the dev work for their feature - to our dev standards
@ashley.noble I am leading an internal community of DevOps guys - goal is to exchange knowledge and learn but also to act as a platform for alignment.
@bernard.voos mostly we took it from Accelerate, but I think they're pretty close
A deep dive into all the pieces that make up a pipeline, and all the technology involved. A big challenge, given many hadn't ever worked with containers before.
Metrics: Are you measuring on team level or aggregate? And how do you measure cycle time? We try to measure but there are endless discussions about start and end points 🙂.
@ashley.noble It sounds very familiar that creating self-service tools does not always work out as expected.
Isn't the start always form the point you merge to mainline and end is when you are running in prod? Everything else is a potential bottleneck to measure
Tim, I agree. But unfortunately in our case teams do not generally have a useful definition of done = in production.
@tim.wyatt Agreed, but measuring the middle points is useful because you can see the batching (from "The Goal" Book)
@robert.ruzitschka Since we owned the whole pipeline, we built "tags" throughout every tool to measure when a commit made it to that stage, so we could measure it at each point.
@tim.wyatt, @ashley.noble: I wanted to mention something, forgot it and now it came up again 🙂. If you want to focus on the reduction of cycle time, is it meaningful to start measuring with the commit? The story could already have been in progress for weeks (including the respective feature branch). We tried to convince team that the relevant KPI starts with the state "In Progress". What do you think?
@robert.ruzitschka I think there are a number of things to measure: • flow of work requests (stories, requirements, etc) into a teams backlog • Flow of work from backlog into "To Do" • Getting work done (from the point an item enters "in-progress" to "done" • Lead time from merge to prod (IMO)....
@robert.ruzitschka we measure at all levels (individual, team, Release Train, Organization). We don't publish Individual. We found proxies for lead time that were merge to master (start) to when that commit was deployed to production (end). We also measured the intermediate points so we could demonstrate batching from Ops.
Do you have a change management approval function? Have you been able to automate that?
there are many other things to measure prior to this point (esp. in SAFe 🤢) like flow of work into teams....(but not really "devops")
Thanks, Ashley. Great and very realistic insights. Highly appreciated!
great content @ashley.noble. Thank you for sharing your experiences. I'll be watching that again!
@gus.paul yes, mostly we have dashboards to show go/no-go, but we do also have some manual steps from other functions that we're working to build trust in our testing in order to allow us to deploy
Thank you @ashley.noble for sharing
@clarkjas, mostly all the items we ran as part of the pipeline, so make sure the security tools ran on that commit, make sure that the functional tests ran and passed, make sure the performance tests ran and passed.
How did you get the infra teams to trust the dev teams, even enough to let them in the door?
@me1208 and @matthew thank you for your talk. Great to get an update on Team Topologies and the great work you are doing. One question - do you have any good examples of Team API definitions and/or templates? Is there a http://swagger.io yaml template for example? (Because everyone needs the chance to use more yaml 😂)
Hi @mark.rendell have you seen the GitHub repos? This one has a lightweight example of a Team API https://github.com/TeamTopologies/Team-API-template
Ah sorry no @matthew I'd missed that and only looked at the shapes repository. Looks useful, thanks! Anyone out there got some examples that they fancy sharing please?
There is an article here on Team APIs https://medium.com/agile-outside-the-box/team-apis-af2dbc1805e7
@tod.bickley how has the IAM team reacted to the general change?
@matthew.cobby First we had leaders from App Dev come to Infrastructure. Second, we showed people results. The journey with the rest of the Infra team continues...
@christian.rudolph Actually very well. A few outliers of course, but most everyone has leaned in to the change.
Great to see such clarity around the product manager and owner roles! What are their reporting lines?
@helen.beal We all report in the Technology Org. Split between Risk Management and Infrastructure. We have a pretty solid 1:1 match
is there a certain cadence you use or any special meetings to keep everyone aligned?
@katharine.chajka Yes. We have daily 15 minutes standups, quarterly Big Room Planning and monthly Town Halls. Try to make them quick and to the point
@tod.bickley How did you achieved solutions that everything should be in Jira (only) related with UserStory?
@marcin.praczko1 We essentially made it a requirement. If people talked about work they were doing that wasn't in JIRA (outside of OPS work in Service Now) we pushed it all to Jira
@tod.bickley What about emails - requests coming directly via chats / emails / etc - did you have some person who put those requests to Jira?
@marcin.praczko1 For the most part yet. If they were "quick hits" maybe 10 mins or so, we would do them. If it's more that an hours, it's a JIRA card
And really this is more of an art than a science. A loosely defined set of rules empowering engineers
@helen.beal We somewhat automate. Ours TDP's still manually pull the metrics to put into a biweekly communication
Thanks Tod - have you looked at integrating the DevOps toolchain for visibility or adding a value stream management solution on top?
@tod.bickley how do you avoid your JIRA becoming a complicated disaster where it takes ages to create and move tickets around? :thinking_face:
related to velocity - do you use flow metrics for predictability or still more estimation/story points, or both?
@tod.bickley So you still had '5 min task (in your case 10 min)' to deal quickly (ad-hoc) without Jira. Make sense.
@philipp.boeschen650 They key is having the TDP's triage these. They are such a key role
TDP Is the Technology Delivery Professional. They are scrum master like, but are also technical. They manage cards AND pull cards
super interesting about the TDP role - I feel like it was how SM used to be back in the day haha, funny to see so many FT SM now
That's an interesting approach, I like that 🙂 Have experienced super positive things with similar roles inside of gaming a few years back
I've been silent listening to this talk as every single moment is so full of really interesting insights and experiences. This is possibly the single most dense presentation in terms of golden nuggets of experience. Can you just come work for us please? @tod.bickley ? This is the problems so many of use face with Infrastructure teams and the shift the value flow/devops/digital transformation.
@tod.bickley - Great Presentation!
Thanks @tod.bickley great insights
Enjoy the talk from me and @me1208, everyone 🙂 Looking forward to the discussion here soon :thumbsup:
Welcoming our friends and IT Revolution authors, @matthew and @me1208!
Hi everyone! Looking forward to your questions 🙂
Team Topologies Core Concepts seem to be already well established in the community as there are not too many questions :-)
Now you can attend the academy and in 3h you can pretend you've read the book Filip :rolling_on_the_floor_laughing: https://academy.teamtopologies.com/courses/team-topologies-distilled
Thanks Manuel 🙂 sounds like a prerequisites for this presentation 😉
cognitive load has been hugely useful as a tool for me in looking at our teams, and highly predictive - overloaded teams fragment into specialists, it's a clear indicator of where to go looking for fracture lines and break teams up or reduce load
honestly, no - the teams in question are very obviously overloaded :face_palm:
Nice heuristic @kevin986 ! Hadn't thought about it in that way, but makes sense: "over specialization as a smell for too high cognitive load"
Basically, it is not quite a team but a set of specialized individuals with not enough cohesion. Right?
Seriously though - you've given me an idea... I'm reaching out to some of the work neuroleaders at the moment on another initiative (like David Rock and Britt Andreatta) - I shall see if they have any nuggets. As you both know I am a tad obsessed with this subtopic of yours!
That would be great. Manuel and I are exploring how to scale assessments for team cognitive load - we have some PhD level expertise involved, too 🧠
also helped explain to a new manager why his team was behaving the way it was, and why "share the knowledge" wasn't working within the team
"The worth of certain leaders can depend on how many people report to them" We need to address power structures, indeed.
We were referring to the Accelerate / DORA metrics and we often recommend to look at flow efficiency at least
Hi @matthew and @me1208! How do you see the dynamic between strongly opinionated platforms and the optional approach to using the platforms?
A platform can be strongly opinionated without requiring anyone to use it
The opinionated platform MUST be informed by the needs of teams builing software in that organization, however.
Opinions are no good if they are not suited to the context
My experience is that in many cases teams severely underestimate the effort to manage and maintain things that could be put into a platform. This reduces their capacity to provide business value. That is why cognitive load is a very useful concepts to frame these discussions.
Of course platforms must cater to the teams needs and must not hold them back or slow them down.
Platform is a product, and most products succeed because they are opinionated in a way that meets users needs (i.e. provides differentiation vs other similar products).
In internal platforms we need to be looking much more at: product adoption lifecycle and value proposition (differentiators) for internal teams.
If it's less cognitive load to use AWS directly than the internal infra platform, we've done something wrong.
Mandating the platform only exacerbates the problem.
Do you see a role on the platform team to be almost a marketeer/salesperson for the platform?
Sadly, mandating use of the platform is what I see too often - devs are compelled to use it, rather than it being a compelling product that they choose to use.
https://devopsenterprise.slack.com/archives/C0150HQB6UX/p1621347040138500?thread_ts=1621346631.119600&cid=C0150HQB6UX Absolutely, @bernard.voos - a skill often lacking in platform groups is marketing of the platform to internal customers.
At some point, if you have resistance to the platform that interferes with the creation of a cohesive product, persuasion no longer works. How do you combat that?
Why is there resistance to the platform? Is the platform meeting teams' needs?
What incentives are in place to help guide the teams towards something more coherent?
Our platform includes our messaging system, common UI libraries, ... In general we get pushback on the UI pattern. Many time it comes down to "prove that this is the best solution". The answer that is is a "good enough solution" that we can iterate on over time is sometimes not well received.
Don't look at platform adoption as a "combat", you shouldn't be convincing teams, you should be making their life easier (and market how you do it internally).
If they have no need for it or have other needs that are already met, what is the benefit in "standardisation"?
It's an important trade-off that needs to take into account the sense of "ownership" in the teams
We don't have time to convince everyone, and in order to get our separate domain services to play well together, we need some standards for how they are built. The last thing we want is 50 different ways to attempt to make things work together. It slows the other teams down when trying to integrate and makes it more difficult for someone to change teams.
Have you tried changing the incentives around onboarding and integration?
Add "ease of onboarding" and "ease of integration" to each team's balanced scorecard
We're not up to score cards yet. We are still getting up to speed with new teams, new pipelines, devops...
Ultimately, though, some needs are not being met by the platform as it is: maybe DevEx/DX, docs, support, etc.
Sometimes it's just a person. Some people have very strong opinions that don't align with the rest of the teams. If that is a strong personality compared to others in a team, you get this kind of situation.
We are moving towards a set of architectural requirements that allow the artifacts from the different teams to work smoothly together in a consistent way. We can iterate on those requirements based on feedback and the emergence of new technolologies.
That should help, just be careful requirements are not "abused" in the sense you can make them so low level that you're basically telling people how to do their work 🙂 It's a fine line, obvisouly.
Yes, and we don't want that. Ours are more communication patterns between team artifacts that make them work together easily and consistently. This reduces integration time since you know what to expect from another team.
Cognitive Load is quite an eye opener when you haven’t heard of it before. Thanks for putting a spotlight on it.
Indeed. Netflix used the DevOps Topologies internally extensively: http://devopstopologies.com
These are in fact the precursors to Team Topologies 🙂
Do they? And yet "Netflix doesn't do DevOps" :rolling_on_the_floor_laughing:
I'd rather say they do DevOps without calling it DevOps because... they don't need to.
Yet they look at available approaches and what can be useful in their context. Very different from so many orgs who just want to put a "DevOps stamp" over their image
"Complicated sub system teams": this is a notion which I frankly try to put on the side and not use. In fact, I have not seen a place where I needed those.
Great - keep it that way, Olivier! That's what re recommend in the book. Use a CS team only if truly needed.
in an automotive ECU - I see some need for complicated subsystems
Can we hire you as "evangelist" @olivier.jacques? 😄
For the anti-patterns related to sub-teams / internal teams, is a good proxy to measure number of tickets to raise from epic/feature to code to Production? #ask-the-speaker-track-3
The number of tickets needed to get some code into Production would be a in interesting measure, @manzi.g - ideally, the number of tickets needed would be 0, zero, zilch, null, none, ...
But it's ok if the stream-aligned team is offering a service (rather than a product) to customers? It's just when they are torn in multiple (and internal) directions? Can we say value stream aligned?
The service/product thing is a bit blurred, but the key thing ehre is that a Stream-aligned team should have a single focus (customer), not trying to serve two or more customers.
@olivier.jacques I was running a project last year (terraforming and "ansibilizing" SAP builds) with 4 teams broken down by cognitive load and the complicated subsytems team was clearly SAP expertise
I would say sensibilizing now that we have most SAP products e.g. S4 HANA end to end on any major cloud stood up from scratch to functional working app in under 3 hours . Anyone who has done it by hand would tell you it takes weeks usually even in 2021 to build anything close to prod grade and scale. Thanks to TT we did it pretty well
That's awesome. Sounds like this would make a wonderful industry example if you're up for it @pulak.a.agrawal;)
Awesome, will ping you later via email or Linkedin.
One of my favorite TT resource is the drawio/diagrams.net library at https://github.com/TeamTopologies/Team-Shape-Templates#drawio--diagramsnet
in automotive the regulatory requirements are driving high levels of cognitive load
more time spent on regulations than on the customer
Is there an opportunity to simplify the detail of the regulations via some kind of platform, @chris.gallivan278?
there is an industry std architecture called Autosar that attempts to abstract some of this away - this has a side effect of dumbing down the engineers imho
Regarding compliance as code: GitOps seems to solve some of the problems in this area. Any thoughts on this?
there is an attempt to use modeling and code generation tools to an extent
I'd try to start with a regulations enabling team.
A group of experts (likely not from IT) that could help most stream teams raise their understanding of the fundamental constrainsts in the regulations.
At the same time, look for opportunities to automate some of these checks. But sounds like fundamentally teams don't have enough awareness of regulations.
In fact, they need to increase their "germane cognitive load" on that front it sounds like.
(yes, cognitive load is not always bad as we explain in the book and in our Academy)
Thank you for the insights @matthew, @me1208
Great questions as always Helen! Nice to hear from you!
I'm struggling with the anti-pattern around a stream-aligned team providing a service. Are you saying that any internal service would be provided by a platform team then?
we are having a notion that any team in the org can provide an enterprise-wide and / or external service delivered according to a common service standard
The difficulty comes when a team ends up with multiple customers because that leads to priority clashes.
Yes, absolutely. If a team decides to provide a service, they take the full product ownership for the service.
We agree with people like Marty Cagan that a Stream-aligned team (what Marty might call a product team) should have a single real customer. As soon as that team starts providing (say) some data "as a service" to other internal teams, they then have more than one customer. Far better to expose that data via an API< have a platform ingest that data, and then provide the data back out as apart of a proper platform experience.
Even for functionality the same problem applies. It's quite hard for a team of up to 9 people to do proper service discovery (which is part of a stream team's responsibilities) if they see every stakeholder as a customer, both internally and externally.
OR... give the Stream-aligned team enough time and space to truly provide a service to other internal teams, ... But that can get messy very quickly.
Separate concerns require separate teams. Otherwise, you'll likely see external customer needs always prioritized over internal customer needs.
Is there a limit in separating concerns? We ended up with a single, well-grained service, that is consumed by both internal and external customers. It's so small, that there is no chance to further distill it. Building a platform for it looks like an overkill...
If there is no overhead on the team from this, then (by definition) you have a decent solution, @lucjan.giza 🙂 Just look out for the situation where the scale changes and a Platform is needed. BUT - as always - only introduce a platform when flow is impeded and/or team cognitive load is too high.
Thank you @matthew and @me1208!!! That was great and the music transitions were sweet
The music bits you have to thank @matthew the trumpet player :)
👏 Thanks for the talk Manuel & Matt - that was great. Lots of announcements there too
What better place than DOES to announce new initiatives? 🙂
I see no big difference between stream aligned and platform teams. The have different customers. But many of the the "product" team principles apply to both.
The "Platform" is really a viewpoint, a wrapper around a different set of needs or focus
In the TT book we clearly say that inside the Platform there should be mostly Stream-aligned teams... just focus on on platform-y things (data? infra? design?) rather than end-customer services.
@matthew @me1208 Great talk! I really appreciate all of the additional tools and resources you are providing. You're making a community effort out of this, which makes it so much more likely to gain traction and be transformative. Thanks!
Reading that really makes it worthwhile, honestly! Thank you!
@cornelia will have a talk Thursday on GitOps and business benefits. I don't if she'll touch on the compliance as code as a topic.
Hello everyone ... Looking forward to discussing about DevOps for Salesforce with you!
Thank you so much, Matthew and Manuel! We now welcome @abd3721, coming up next!
Excited for this talk @abd3721, i'm already believer devops principles can be widely applied to so many other areas
raise your hand if you are old enough to know what a rolodex is. i'll start 🙋
Thank you everyone, insightful questions as always! If you need any info on the new resources and tools we mentioned, just drop us a DM here or LinkedIn or email: <mailto:firstname.lastname@example.orgemail@example.com> or <mailto:firstname.lastname@example.orgemail@example.com>
Anyone here already managing a development lifecycle on Salesforce?
not me personally , but i know our salesforce team has been working on a big bang data project and struggling to launch it successfully
I'd be happy to connect with your team at some point if that would be useful
thanks.... it definitely may be.. will reach out to you if it makes sense to connect about it
@me1208, @matthew - will you be available for discussion in Gather zone / Birds of a Feather?
I cover Salesforce DX (somewhat briefly) a little bit later in the talk
Kinda sorta. The DX initiative basically opened up a huge number of new improvements that makes things better for everyone. There are things that only Salesforce can improve.
Nice that you're up to speed on the options @joachimsammer. I obviously get a skewed perspective, but this topic of "DevOps" has become a bigger and bigger deal for Salesforce customers. It's top of mind for most big Salesforce teams
@abd3721 maybe a bit offtopic - but the similar challenges exist in the SAP world as well. And as I'm from the data domain - just wanted to ask: Do you have any insights/experience on "DevOps for BW?" /4HANA, or DWH Cloud, or SAC - whatever
I don't have direct experience on SAP, but Copado is starting to work on that. You could connect with them in the xpo-copado channel
You'd love it @matthew Merge works fine as long as there aren't any repetitive elements. But, a 100,000 line long XML file is basically filled with repetitive elements.
You've got to parse it and merge it intelligently if you want to manage that XML at scale
Database Monoliths for the win! @me1208 @matthew
Manuel and I once worked on a monolithic database system where it took over 24 hours to build the new code - this was in 2016
A developer VM in the cloud took 40 minutes to start
Almost all the business logic was in the database, but not even accessible as normal SQL - it was generated from models in a proprietary language - woo!
Needless to say, development there was not rapid...
The term "database monolith" won my heart when I saw that in team topologies, since it describes Salesforce and the challenge of modularizing Salesforce. Miraculously, they've engineered things such that migrating and updating the Salesforce data model is super fast, and is not the limiting factor at all. The limit is on your ability to modularize your applications since they all get intertwined with the big database
That is good to hear. As always, the focus should be on a fast flow of change... and supporting technologies to enable that. :thumbsup:
Note the vision for separating stream-aligned teams from platform teams
Thank you so much for this fantastic tutorial on the Salesforce ecosystem, @abd3721!!
Very grateful for your invitation to share @genek!
Salesforce packages all become part of the common Salesforce data model. So they're not isolated the way you might expect on some other platforms
That's what makes it tricky to decouple metadata into packages
Yep, so just a way of structuring your code and config. The underlying architecture is still the same SF core and add-ons.
Yes. There are some hard distinctions between packages - commercial apps can protect their IP, and get additional runtime (governor) allowances
But even though Salesforce packages don't segregate things very deeply, they at least provide some formal statement of where boundaries exist
That reduces the risk of confusion about who needs to change what, or where the risks of a change may lie
Just curious, @abd3721: How much time do you have to spend trying to convince Salesforce developers to use version control? cc @jason.cox
... cuz you know, who needs to remember history, right?
Salesforce teams like the idea, it's just sometimes daunting if they feel they have to go to the command line, if they didn't come from a coding background
And Salesforce metadata doesn't make it easy. It opens up some problems that most code projects don't struggle with
VSCode is pretty good for Git integration, to be fair. There is even an official Salesforce extension pack! https://marketplace.visualstudio.com/items?itemName=salesforce.salesforcedx-vscode
With VSCode, there is (often) no need to drop to the command-line.
The introduction of VS Code to the Salesforce community has been a huge win for those who write code on the Salesforce platform. The challenge remains that you have a lot of non-coders collaborating on changes, and they also need to manage their changes alongside the coders.
@genek101, we had a similar challenge in Data Warehouse domain. Convincing DWH Developers to use git was a starting point. But you know - understandable Diff + Blame made the magic :)
So you have to span the skill boundary between the click-based folks and the coders, maintain a shared history, and be able to deploy stuff that's not just code.
Also testing in between. We invested our focus into a fast CI - which validates the whole data warehouse model with all dependencies on each commit.
Yeah, it's amazingly powerful when you can get such automation in place. Version control is the only big hurdle
Agreed. Version control is hugely powerful but it's not hugely accessible... yet. Interesting discussion/rant here: https://twitter.com/matthewpskelton/status/1387521384226643968
PS: in confidence, I miss the simplicity of SourceSafe — the ability to share files was so awesome. (forget the occasional database corruption issue.)
@matthew, oh, I've been in exactly the same discussions :) Unfortunately a lot of tools do not provide first-class version control. Take Office365 - saves all versions automatically. But where is the diff, pull request, etc.? Finding out what changed is very tricky. In my eyes it slows down collaboration dramatically. "What am I looking into, what's the story someone else wanted to tell by modifying 5 slides...." Have no recipe how to get git accepted for WYSIWYG guys...
I intend to write up some of this stuff but the short version is that the solution here seems to lie in custom visual diffs based on file types. So an AutoCAD file gets special 3D visualisation diff An Excel file gets a custom column-based diff etc.
would be a dream come true 🎺