May have asked this before but couldn't get an answer from any of the "experts" at my company so...

How do you store/pass in db login and certs for testing/debugging from your own machine?

I'm using Java Spring and the way I'm thinking of is to override the application.yaml, in the Debug configs, to point to one that has the credentials but only shared within the team?

This is why companies have security policies

The right approach is to use profiles

https://baeldung.com/spring-profile...

your development repository should have several application properties

application-develop.yaml

application-staging-yaml

application-master.yaml

or something like that depending on the project and company setup

there should also be one main application.yaml that specified the active.profile as "develop"

on the staging or master environment this should be overriden either in the branch, or using environment variables

you should then create your local database to have the login info and table names as the develop properties file describes

ideally there should be migrations or an import.sql somewhere in the project that gets that running

Ideally you'd want to setup the repo and project in such a way, that any dev can get it up and running locally in a matter of minutes.

worst case scenario you literally have to just keep a separate copy of the application.yaml file that has your own locals configured, but it would be much better if this was done at repository level to some extent

@Hazarth well for our local/debugging, we need to connect to at least UAT db to get enough test data.

Our tests are more integration than unit tests.

And in non local. The db is also remote so need to login.

@dan-pud they don't help if they don't define the right way or any way to do it...

@donuts

Ah, that makes sense too.

Still the same applies... I think I just now understood what you're actually asking?

To be honest we always stored development credentials in plaintext in the repo (private) or was just shared around by people. Thought I think no one ever actually gave the devs access to actual UAT environments now that I think about it. We only ever had access to in-house testing environment. If something happened in UAT we would get the bug reported, usually our tester would try to reproduce it and then write up a proper ticket with example data on the testing env.

storing actually secure credentials is finicky. I guess Spring does support cloud configs, so technically the configurations could be stored in a cloud instance and distributed to the devs I guess? but I actually don't have experience with that so I'm not sure if this is a valid use-case hmmm

do you have a company computer or your own?

@Hazarth company creates a VM and we login either remotely or from our desks.

Yes we thought our dev repo was private but apparently since we changed to Bitbucket years ago and used central build servers... They no longer were...

Except no one actually said so explicitly so now kinda trying to clean up.

We don't have a testing team and part of the argument is "cuz theyd just show us down"

Which sadly may be true... Getting support teams for like hardware, database, system issues to actually do something takes like weeks of back and forth...

Give me admin, probably can get it done in a few days unless needs some specialized knowledge...

@donuts

not having admin access to almost everything as a skilled dev is pretty painful...

I remember a time when I had pretty much full power over all systems in the company, and then one bloke showed up and said "hey, we should do proper access control" and I was blocked out of stuff and suddenly everything took 4 hours longer because I had to involve another person...

long story short, I got into a verbal fight with the dude and moment later I had my access back while we also enforced proper access control on others! good times

anyway, can't you maybe ask for a copy of the UAT database and run a local copy of the data to reproduce bugs? maybe a synchronization task could be written to provide some sort of shadow copy of the UAT for the devolopers environment so you have an up-to-date copy without getting direct access?

@Hazarth yes we have a sync task... From prod to uat. Essentially uat == uat/dev.

We need to sync from prod because a lot of upstream systems don't provide data in uat...

So let management decide... I just want to reduce the amount of rework I need to do...

Don't like doing something and a yr later someone goes "that's not right, fix it asap"...

Well now that an entire app was built on top of this...hm....

A: hack it with some ugly duct tape fix
B: burn the whole thing and start over the "right way"...

Most likely answer: A

I have never managed to find time to completely rewrite apps... Even small ones.

And I'm the only person on my team that writes small apps.

6 months later... App randomly crashes for some unknown reason...

@donuts yeah, rewrites almost nevwr happen. I get it, because it costs money and It's already done, so why should we make it twice buuut... Imo it costs more money in the long run to maintain a messy app

I remember one time, we had a really buggy shopping system that was the result of about 40 change requests that weren't planned (not kidding, the client was nuts). The system was there before I even joined the company and people kept patching it up and new bugs kept piling up, we had a bug or two related to this system every sprint. It took me some time to convince everyone, that this *needs* a rewrite, at least that one part...

Lo and behold, I rewrote it in 2-3 days completely and re-connected everything else to it and since then the bugs stopped comming in except for a couple here and there, but that's normal

At some point it really becomes worth it. I guess that's what's called tech debt

@Hazarth ya we are actually rewriting some apps or (large) APIs to microservices.

I'm supposed to be looking into how to do it the right way... And well I'm pretty lost... Sorta just trial and error...

But at least I have a better sense of what a good general direction to go in is. Hopefully...

For me though, it's still slow and steep learning curve... And well documentation (on the internal components and style) and help are scarce...