Improve developer experience and productivity

[snowfrogdev]

• DevBetter as a project provides value to its community and to its owner, but one can imagine that that value is not counted in the billions of dollars (not yet 😜). At the moment, for DevBetter community members and its owner (and agents), time spent working on the project provides limited ROI.
• DevBetter does not really have a pool of dedicated maintainers for which DevBetter work is a high priority. Which is normal when taking into consideration the previous point.
• The DevBetter project, though not very large in size, does rely on a number of third party services (Azure, Vimeo, Discord...).
• At the moment the repo is open source and we have to be very careful about secrets and credentials leaking out.
• Getting DevBetter up and running locally is not the most complicated thing in the world but is also not exactly trivial.
• Given all of the above, individual development efforts by community members and the owner is probably not as efficient as it could be.

If we want the DevBetter project to be maintained and developed to a certain level of quality by community members, which is no doubt one of the main benefits of having it be open source, getting up and running should be as easy and as fast as possible. My personal experience so far is that it isn't, for a number of reasons.

I've created this issue so that we can all come up with some ideas, hopefully some low-hanging fruits, that could potentially improve developer experience, speed up onboarding and generally increase development ROI.

One of my personal pain point has been working with features that integrate with 3rd party services, but I believe there is room for improvement in the CI/CD process and other areas as well.

[snowfrogdev]

Here are some general ideas generated by ChatGPT. Would applying some of these for devBetter make sense?

Here are some best practices for providing a good development experience to developers while keeping production secrets and credentials secure:

Use environment variables: Store all secrets, credentials, and configuration data in environment variables rather than hardcoding them into code or configuration files. This allows for easy configuration management, as developers can set these variables in their local environment or use tools like Docker to spin up containers with the necessary variables preconfigured.

Use a secrets manager: Consider using a secrets manager, such as AWS Secrets Manager or Hashicorp Vault, to securely store and manage secrets. This allows for centralized management and access control of secrets and reduces the risk of secrets being leaked or compromised.

Use mock services: Mock the third-party services or use stubs that simulate their behavior, so developers can work with the integrations locally without affecting production accounts. This also reduces the risk of accidentally sending test data to production environments.

Use a sandbox environment: Create a separate sandbox environment that closely mirrors the production environment, but with isolated resources and accounts. This allows developers to test integrations in a realistic environment without impacting production accounts or data.

Use version control: Use version control for configuration files, scripts, and other assets related to third-party integrations. This allows for easy rollback and review of changes, as well as collaboration among developers.

Use automated testing: Use automated testing to validate integrations and catch errors early in the development cycle. This also helps ensure that integrations remain functional as changes are made to the codebase.

Document thoroughly: Document all third-party integrations, including their configuration and usage, to make it easy for developers to understand and work with them. This also helps new team members get up to speed quickly.

By following these best practices, you can ensure that developers have a good development experience while keeping production secrets and credentials secure.

[ardalis]

Local developer setting could go into the ReadMe without creating merge conflicts in source. It would just have placeholders, and some docs on how to get started fresh on a new machine or for the first time.

[ShadyNagy]

We can create Web Application in DevBetter to be a simulator for discord and put these links on the development settings and we can see the messages on our simulator pages.

[snowfrogdev]

Local developer setting could go into the ReadMe without creating merge conflicts in source. It would just have placeholders, and some docs on how to get started fresh on a new machine or for the first time.

This, I think, is a bare minimum and would already be a nice improvement.

Instead of the settings being in readme though, we could make a appsettings.Template.json as suggested by Fati Iseni in a previous discussion.

But we should definitely have instructions in the Readme on how to set EVERYTHING up. This being an open source project, we would want to take very little for granted and make the barrier to entry as low as possible for people that may be unfamiliar with .NET or our third-party integrations or even software development in general.

[ardalis]

For development Discord maybe we could use a docker container? https://github.com/davidk/docker-discord

At a minimum we can include instructions for setting up your own (actual) Discord server. It really is a 2 minute one-time endeavor, and many developers may find it useful as they can then do things like set up GitHub webhooks that go to channels in their personal Discord server, etc. (I should blog about the benefits of having your own Discord server)

[KyleMcMaster]

Local developer setting could go into the ReadMe without creating merge conflicts in source. It would just have placeholders, and some docs on how to get started fresh on a new machine or for the first time.

I've included an appsettings.Development.Sample.json on projects in the past that developers copy and rename to appsettings.Development.json (which is ignored by .gitignore) in order to get them up and running quickly. Of course this doesn't get them around any secret generation but for non-sensitive settings this can be an easy way to get started quickly.

Edit: Just saw Phil's comment about a template approach and this is basically the same.

[snowfrogdev]

For development Discord maybe we could use a docker container? https://github.com/davidk/docker-discord

At a minimum we can include instructions for setting up your own (actual) Discord server. It really is a 2 minute one-time endeavor, and many developers may find it useful as they can then do things like set up GitHub webhooks that go to channels in their personal Discord server, etc. (I should blog about the benefits of having your own Discord server)

At least the Readme does have some mention of the need to set up your own Discord server and a link to a blog post on how to do that. I'm just hoping that we can find a way to remove that friction, if it is at all possible and cost effective to do so.

[snowfrogdev]

@ardalis how about creating a private "dev-test" channel in the actual DevBetter Discord server. You can give access to whom you want, presumably all active DevBetter members, but you could restrict that further. For ease, you could pin the webhook url in the channel. We can then add corresponding instructions in the Readme. What do you think of that approach?

[ardalis]

Sure I'm fine with that. You still haven't tried creating a Discord server, have you? 😉

[ardalis]

Done

[snowfrogdev]

Sure I'm fine with that. You still haven't tried creating a Discord server, have you? 😉

No need to create one, I already have one. 😜 I had to bring it back from the dead, but it's there.

I'm just trying to think holistically about dev experience. Discord is probably the easiest of all our 3rd party integrations to deal with. Vimeo, Stripe, emails, etc. are a bit (a lot) more of a pain.

[justin-appointmentreminder]

If it interests anyone.. thought I should contribute considering all the hassle I am, but cloned the repo, did the EF migrations.. doesn't run... no idea why