Good thread about Dotnet people on Mastodon
magbeat
Yes, you are right. Long living branches are the problem.
In this case it is a completely new project in the workspace (of course depends on the library in the workspace). It is a POC that has been postponed again and again by the customer due to priorities.
I think it's probably best to isolate the branch and take it out of the workspace. When it is ready, we can integrate it back into the workspace.
As @[email protected] said you can use multiple configuration providers. We usually have local appsettings.json
files, even per machine appsettings.<HOSTNAME>.json
and then use Environment Variables that are stored in a vault for the production environment. We add the appsettings.<HOSTNAME>.json
files to .gitignore
so that they don't get checked in.
var env = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT");
configuration.AddJsonFile($"appsettings.{env}.json", optional: true, reloadOnChange: true);
configuration.AddJsonFile($"appsettings.{Environment.MachineName}.json", optional: true, reloadOnChange: true);
configuration.AddEnvironmentVariables();
Then you can provide the secrets as environment variables in the form of DATA__ConnectionString
When you are developing a UI library (as we are) we want to support the old API for some time and mark is a
deprecated
. So one would add a second@Input()
of typeScheduleEvent[]
leave the old API be asCourse[]
and mark it as deprecated. In the next major version you could then retire the old API.