red-gate / tech-radar Goto Github PK

In Prompt:

• Sonarqube - Explore

I've used quite a few other tools in the past such as Pc-Lint, NDepend, FxCop/StyleCop and Coverity. The latter is by far the most powerful one but it's quite expensive...

I notice lightweight ADRs are in the Adopt section of Thoughtwork's tech radar:

Much documentation can be replaced with highly readable code and tests. In a world of evolutionary architecture, however, it's important to record certain design decisions for the benefit of future team members as well as for external oversight. Lightweight Architecture Decision Records is a technique for capturing important architectural decisions along with their context and consequences. We recommend storing these details in source control, instead of a wiki or website, as then they can provide a record that remains in sync with the code itself. For most projects, we see no reason why you wouldn't want to use this technique.

This is a practice used by some Redgate teams already.

Should this be in our techradar? If so, where?

I'd suggest in the Techniques quadrant, either in Adopt or Explore?

This has caused problems with DLM Dashboard and I think we're trying to get rid of it.

Use a JavaScript library?

Use Thoughtworks?

Any other?

We use a single one in Prompt:

• Ninject - Adopt

We're enduring serial key based licensing and adopting login licensing, I think? Should we put other licensing considerations (user vs per-server vs other size-calculation models, perpetual and S&U vs subscription) on here, or is that too distant from tech / decisions teams can make themselves?

Should the radar include which .Net frameworks we should be targeting?

Adopt:

• .Net Standard
• .Net Core

Endure:

• .Net Framework >= 4.6.1

Retire:

• .Net Framework < 4.6.1

A few of the suggestions are proposing to put some items under Adopt and some of them have no trial or previous success associated to them in context of our product teams (as far as I am aware of, I could be wrong). #35 is a good example to this. Even if the approach is a very successful one and has been battle tested for years, we have no experience of using this for our products. Therefore, I don't think it would be healthy for us to put items under Adopt ring if they don't have any previous success attached to them in context of our product teams' experiences.

I propose that we restrict Adopt to only items which we have tried before and show strong sings of success.

There are a few outcomes I expect us to achieve through this change:

• Make it more clear what Adopt ring means to us.
• As a result of above, we should be able to make decisions faster on what should go into here.

Is this something that is in Endure in general, both WPF and Winforms?

What about for SSMS / VS plugins - is WPF still an Adopt approach in that specific case?

What's our position on various ways of making web UIs in standalone tools (e.g. Electron, whatever it is that ANTS and Monitor uses)?

Can we all agree that CEF belongs in Retire?

So just cos I want to be that guy...

Endure - This is no longer how we do things. It is OK for this to be used in Product Development, but don't add more of it and migrate off it wherever possible.

I don't see how JS can be put in this ring. A lot of people like TS, but I think there's a time and a place for plain ES6+. Eg at the start of a project, only adding the extra layer if/when needed .

I personally haven't seen a significant benefit over using TS and found the tooling and extra layer to be more of a hindrance.

The Spiders team have been exploring ways to make ever green architectural diagrams of the data catalog. As a result, Lucidchart has been put on the table.

Why is maintaining an ever green architectural diagram important

• Per description in #42, the team is investing time effort into adopting DDD pattern into SQL Data Catalog, one of the foreseen difficulties that we need to overcome is adopting its Ubiquitous language
• DDD is something the team hasn't had previous experience with in the past
• There is a strong emphasis on carefully designing the domain layer, namely the aggregate's consistency boundaries

The belief is that having visualised architectural diagrams would relief us the above pains we will be experiencing.

Benefits of using Lucidchart

Some of the functionalities we could take advantages of:

• Individuals in the team are able to create/edit the diagrams, which can be shared across the team
• Make responsive comments on individual components on the diagrams for better communication
• Ability to zoom into lower level architectural diagrams, by adding hot spots on particular components on the higher level ones

We don't make extensive usage of them in Prompt (only for importing/exporting settings, which by itself is an obsolete capability in the product we want to retire in favour of true shared settings), but adding this for completeness.

• Zip file format - Endure
• DotNetZip - Adopt/Endure

Appinsights and our own in house Usage stuff that feeds that feels like it should be on here somewhere. We still have a few other things kicking around (not just SA FUR but also Google Analytics) which I think we're trying to kick?

We currently used at least:

• JIRA
• GitHub Issues
• Trello

And I've got a feeling there are many more.

I suspect at least @Michael-Upton and @cj-smithy have some opinions here 😄

This might be a bit outside of Product for the most part, but in terms of infrastructure management that we do upstairs:

• Puppet in adopt
• Vagrant in adopt (or has it reached endure already?) for development environments

Just creating one issue for these for now since they're all kind of interrelated:

• Technical spikes: timeboxed prototype/proof-of-concept for some feature or technical implementation detail. Usually done with minimal quality (since they're never intended to be real code), implemented on a branch and then thrown away
• Feature flags/toggles: some way to prevent code in master from affecting the way the product behaves. There are lots of different types of toggles: they might be set at compile or run time; they might be purely internal or visible to the user, and so on. Much more details here: https://martinfowler.com/articles/feature-toggles.html
• Spike & stabilize: a technique for delaying investment in code until it has proven to be valuable: every bit of new code is initially written as "spikes" (unlike technical spikes these usually have a basic level of quality) and then after some trigger (eg the code is touched again / the feature becomes popular / X weeks have passed / etc) the code is brought up to a "high" level of quality with full test coverage, better error handling, documentation, etc

We might combine these techniques: eg use a feature flag to allow spikes to be committed to master early, and then turn off the feature flag once the spike has reached a basic level of quality

There's a lot more we could (and have) written about these topics, though :)

We use a single one in Prompt:

• NUnit - Adopt

For new starters finding information is not very clear.

@JonathanMasefield has given some guidance on the Info Site so we should incorporate this in the Tech Radar.

As we have standups on our Adopt list, we really should add Retros as well...

• Adopt - Releasing via a single script
• Endure - Manual releases via the release app

How do we store information in files?

Adopt - JSON
Endure - XML

We struggle with keeping libraries up to date.

We currently have a home-brew system to keep things up to date (Build Bot fires PRs for some of our internal packages), but it's home brew and not perfect.

https://dependabot.com/ looks like an interesting solution, and supports more stuff than just NuGet. It generates PRs covering details of the changes and gives any details of security fixes (see here).

Any teams will to give this a crack? Perhaps @juliahayward and the Toolbelt team?

AFAIK, the vast majority of products now use RedGate.Build, rather than the old build magic.

How much of this is worth capturing on the tech radar?

My gut says:

• Adopt: RedGate.Build
• Retire: build magic

Worthwhile? Is build magic already dead and I'm living in the past? Is there some other option?

Should we be explicitly adopting C# 7 as standard across the organisation, in parallel with keeping projects up to date on framework versions?

In SQL Clone, on every build, in a vagrant VM, we:

• Install the previous release
• Install the agent for the previous release
• Upgrade install to the current build
• Check the agent is automatically updated

This is something we have found valuable, and we haven't found it to be an excessive maintenance burden. I think isolated installer tests are a useful component of having confidence that a build can released without any manual testing.

Currently, we only do update tests; we're considering adding clean install tests as well, although in our situation update is the more important scenario to test as it is riskier, particularly being a server product that has to maintain compatibility with at least the last release's clients.

(The agent part is not relevant to other products, of course!)

Wix 2 in retire, Wix 3 in adopt, probably not looking at Wix 4 yet?

What other weird and wonderful installation tech do we still have lurking in the corners that isn't using the standard RG installer?

A couple of comments have questioned the scope of this techradar. Is it:

• Product-division specific?
• including CoreDev?
• including the webteam?

IF the former, we must consider the other contexts (discussions on Infrastructure management and Supported Browsers proves this, IMO).

Where should our 'standard' CfU implementation be on here? Should it be out in Endure and we should be looking into autoupdate - in which case, what are our promising autoupdate options?

I'd like to propose adding RevDebug to the tech radar in Explore.

We already use it for the Oracle Tools and have a good relationship with the team building RevDebug.

Do we or Core do any? We really should.

https://info.red-gate.com/eng/development-policies/platforms-and-supported-versions looks like some of its contents may now belong here?

I'm trying to avoid this becoming a copy paste of packages.json, but I feel like there are some common choices we need to make around JS utility libs that would make life easier moving from team to team. Thoughts?

Adopt:

• lodash (enumerable functions)
• moment (Date formatting)
• numeral (number formatting)
• highcharts (charting library)

Endure

• underscore (enumerable functions)

Currently monitor supports:

Chrome
FireFox
Edge
IE 11

via Babel's Env preset and babel-polyfill

Pulling this out of #27:

JavaScript and, more also specifically, React testing is definitely an area we haven't pinned down.

We've been using jest for general js testing, which appears to work just fine.
We've successfully written some React component tests with jest and enzyme but haven't found them particularly useful beyond a proof of concept

we have a few different testing stacks so far:

• for running unit tests outside of the browser:
  • jest (with optional enzyme for testing react components)
• for running unit tests inside the browser:
  • karma+jasmine
• for driving an entire web application:
  • figleaf is currently using jest+spectron (which is chromedriver under the hood) to run a basic test against an installed product
  • it looks like monitor has some basic nunit+selenium (which is also chromedriver) smoke tests

Thoughtworks Radar has four rings, which we'll describe starting from the middle:

• The Adopt ring represents blips that we think you should be using now. We don't say that you should use these for every project; any tool should only be used in an appropriate context. However we do think that a blip in the Adopt ring represents something where there's no doubt that it's proven and mature for use.
• The Trial ring is for blips that we think are ready for use, but not as completely proven as those in the Adopt ring. So for most organizations we think you should use these on a trial basis, to decide whether they should be part of your toolkit. Typically we're happy to use trial blips now, but we realize that most readers will be more cautious than us.
• The Assess ring are things that you should look at closely, but not necessarily trial yet - unless you think they would be a particularly good fit for you. Typically, blips in the Assess ring are things that we're currently trialing, on our projects.
• The Hold ring is for things that are getting attention in the industry, but we don't think are ready for use. Sometimes this is because we don't think they're mature enough yet: sometimes it means we think they're irredeemably flawed. We don't have an "avoid" ring, but we do throw things in the Hold ring that we wish our clients wouldn't use.

I think our needs are somewhat different in the context of the New Tech Moratorium.

For example, some tech it's important for us to standardize on (perhaps even across all products) and some tech we want to actually get rid of because it's a pain to maintain that software. I don't think the Thoughtworks rings adequately describe this.

The original Thoughtworks radar gives four areas

• Programming Languages and Frameworks. This was just languages but we rolled frameworks into here with the October 2012 Radar.
• Tools. These can be components, such as databases, software development tools, such as versions control systems; or more generic categories of tools, such as the notion of polyglot persistence.
• Platforms. Things that we build software on top of such as mobile technologies like Android, virtual platforms like the JVM, or generic kinds of platforms like hybrid clouds.
• Techniques. These include elements of a software development process, such as experience design; and ways of structuring software, such as microservices.

Are these the right ones for Redgate? What four should we pick?

https://radar.thoughtworks.com/?sheetId=https%3A%2F%2Fgithub.com%2Fred-gate%2FTech-Radar%2Fblob%2Fmaster%2Fradar.csv
|
|
v

Following the FAQ, I couldn't see any problems, other eyes might be sharper than mine

We have a single one in Prompt:

• Log4Net - Adopt

I've used others elsewhere (e.g. NLog), but currently we have found no need to look into them here.

Personal opinion: For me the first question to ask is whether this is even desirable to have at all.

We use Fody (alongside Fody.PropertyChanged) - Endure / Retire

We use quite a few mocking frameworks

• NSubstitute
• Moq
• Rhino Mocks

Where should they be on the Tech Radar?

Spiders team have been exploring Domain-driven Design (DDD) in our journey towards stabilizing SQL Data Catalog offering. It's early days for the team to tell about what's working, what's not. There are several reasons to choosing to explore this technique:

• Keep ourselves honest about striving for persistence ignorance through proper domain modeling so that we would be able to accommodate foreseen/unforeseen needs around scaling when they make sense to us.
• We are finding it easy to shape the discussions around business language and structure the codebase around the well-established DDD concepts such as Aggregate, Command, Event, etc. The assumption here is that this will make it easy for us to add/remove/amend functionality due to these battle tested concepts as we are making the intent clear.
• There is a great deal of resource and community support behind this. This even is a good guidance on it's own and there is an active community behind this for support and questions, along side the Stackoverflow knowledge which got built-up over time and all the other resources.

I propose that we put this under Explore ring for Techniques quadrant.

side note: I also believe there should be accountability associated with exploring a quadrant. There should be a point that the team should make it visible to the rest of the company what the results of the exploration was and what the recommendation is (e.g. take it to Adopt, make a case for more knowledge investment, stop exploring and endure/retire, etc.).

Currently, the scope of Explore ring is as below:

This has potential and is worth experimenting with in 10% time or running a trial on your team.

One can infer from this that this can be a wishlist of what we want to look into. I can see a value of this. However, in scope of Tech-Radar, it might be more effective to us to constraint this ring to only hold items which teams are actively trying out.

So, I propose that we change the scope of this to emphasise:

• commitment: Only an actively explored item which is associated to a quadrant should be in here. We should also make it clear what the expected outcome we are hoping from this exploration to put clarity on the success.
• accountability: I believe there should be accountability associated with exploring a an item under a quadrant. There should be a point that the team should make it visible to the rest of the product division what the results of the exploration was and what the recommendation is (e.g. take it to Adopt, make a case for more knowledge investment, stop exploring and endure/retire, etc.).

There are a few outcomes I expect us to achieve through this change:

• Make it more clear what Explore ring means to us.
• As a result of above, we should be able to make decisions faster on what should go into here.
• Prevent making this ring to be our wishlist of the hot technologies/techniques/platforms/etc. w/o any real benefit to us.
• As we have accountability associated to each item under here associated to a quadrant, it can make it more clear what the next steps could be. Obviously, it's another matter to make sure we regularly review.

I don't have any personal experience with these, but we seem to use powershell pretty heavily when building automation for products. Do we always want to do this instead of just providing a plain old commandline? Do both?

How should we categorize the tools, patterns and frameworks that the Product Designers use?

Explore - F#
Adopt - C#
Endure - Delphi, C++
Retire - VB.Net

For new projects with a backend SQL Server DB or Azure SQL DB, it would be great to use Redgate's SQL Change Automation solution (aka dogfooding).

Pulling this out of #27:

Does Pester count as a testing framework for .NET? It's for PowerShell! 😁

Are there any alternatives to Pester we should be considering?

We run tests against SSOL for SQL Compare Engine, so it feels like Linux should at least be in the Explore area.

Also where should Oracle be? MySQL, Postgres etc? (obligatory controversial parrot)

It seems we use multiple different frameworks for GUI tests:

• SCA uses Windows Application Driver
• SoC uses Ranorex
• The Toolbelt Team uses Coded UI

Okay, fun time!

Current "adopt" stack for Web UI:

• React
• Redux/react-redux (If needed)
• fetch
• Honeycomb Web Tool Kit
• moment JS
• HighCharts +
• lodash
• SASS
• SignalR

Build:

• Webpack
• Babel

Old UI frameworks

• KnockoutJS - Endure
• RX.js - Retire
• jQuery - Retire

Question: There's definitely a time and a place to use server side rendering ie Razor/MVC, especially when experimenting or if we don't need client side interactions. What ring would that go in?