|
What options are there for centralized config options/keys? One of our projects relies on a single config file that's copied over to every new Dev machine, and when changes in the config file happen, it makes everyone else's outdated and causes problems with failing tests and poo poo. Is there a service that offers a "centralized" config file or ENV variables?
|
#
¿
Jul 8, 2015 14:43
|
|
|
|
| # ¿ Apr 30, 2024 06:01 |
|
|
I've taken it upon myself to create a VM for our Rails project, because our current config setup and new engineer onboarding is a mess. One of our config steps is "export these plaintext passwords in your shell profile and get someone to send you a copy of our dev database" ( ) among other bizarre poo poo. Don't get me started on our data model... Man, I never thought I'd see the day where I'd be looked to as a real leader and force for change and continuous improvement.To that end, I'm puzzling together Vagrant and Chef to make an Ubuntu-Rails-Postgres VM, where all you need to do is install Vagrant and VirtualBox, clone the repo, run vagrant up --provision, wait, and have a VM you can SSH into and run the project in. No figuring out how to install Postgres on each new machine, no moronic database sharing, no inability to do dev work if you're on a Windows machine, nothin'. So far, so good. I've got something really basic working on OSX (and I assume Linux distros as well), although I still need to automate bundle exec rake db:create etc. With Windows, it's been another story, since I don't do Windows dev and had to figure out how to use SourceTree as a makeshift git client, and then found out that our project manager's laptop couldn't handle 64-bit VMs.  I had to downgrade to trusty32. I work for a finance and insurance corporation, so Windows will be everywhere, sadly.I find it kinda fun! I also want get CICD going for the rest of the project, cause I refuse to work without some sort of automation pipeline in place. Better to get it done now rather than later - every project worth its salt moves to CICD eventually. The one hitch in the plan is ActiveDirectory and VPN weirdness. The company is really strict and risk-averse, so it's got its own weird connection issues and the projects rely on ActiveDirectory being available because llllooooooolllll. We want to abstract AD away from the rest of the project, but it's not that simple due to aforementioned private network BS. (Our project has different configuration depending on whether you have WiFi or not. Yeah.) Wish me luck
|
|
#
¿
Dec 18, 2015 15:32
|
|
|
Ithaqua posted:They're not operating on production environments. They're writing automation scripts that will be well-tested and well-understood in lower environments before they ever touch production. You should, at the very least, have a staging environment that is 100% the same as production. Just please, please don't do stupid poo poo like give your 1-month old junior developers full access to your deprecated server templating and environment system and set them off on their own without expecting something to go wrong. God, am I glad I have a job that knows what to do with me now.
|
|
#
¿
Jan 25, 2016 15:08
|
|
|
wins32767 posted:Working in a regulated domain has implications that makes going with Heroku a hard sell, both internally and to our customers. Try working in finance and insurance. Heroku, JIRA, and BitBucket were all banned until recently.
|
|
#
¿
Jan 26, 2016 23:41
|
|
|
We're actually in the middle of implementing CICD for our current apps. So far, we're using a combination of Vagrant, Docker, Jenkins, Make, and a homegrown Elastic Beanstalk tool for building and deployment  One majorly important thing I've learned is not to go too far away from established/pre-existing solutions developed by other members of your team(s), because having everyone converge on one specific CICD solution is incredibly important. Otherwise, nobody knows what the gently caress.It does help a gently caress of a lot not having to use Chef or anything for provisioning, and instead just using Vagrant boxes and Docker images for that bullshit. Just containerize everything, problem solved! 
|
|
#
¿
Apr 6, 2016 14:03
|
|
|
Deployment with Docker is AWS.
|
|
#
¿
Sep 22, 2016 22:00
|
|
|
I've got an application that's developed locally under docker-compose, where the application container is kept separate from the database container. I want to try using Bitbucket Pipelines as an automated regression testing system, whereby branches automatically have their specs run. However, I don't see anything out there on integrating an application that uses docker-compose with Pipelines out there, and I don't know enough about Docker to figure out what I need to do to get it to work, aside from the fact that having an application confined to a single container is apparently not what Pipelines expects. Anyone here familiar enough with Docker, Bitbucket, and Pipelines to help me figure out what I need to do?
|
|
#
¿
Nov 21, 2016 16:18
|
|
|
Ive always seen SRE stuff described as "be on Pagerduty and get frantic calls when alarms go off" while "doing devops" is Docker, CICD, and AWS.  I've dealt with Docker before in a very limited capacity so I listed it in my resume, but apparently it's a whole field of study now. And drat near everything wants AWS experience now. Pollyanna fucked around with this message at 19:06 on Aug 5, 2017 |
|
#
¿
Aug 5, 2017 19:04
|
|
|
Pay at startups is directly proportional to what they can raise from investors, VCs, and stakeholders, so buzzword bingo and hype plays a massive role. I don’t know much about pay at established companies and large corporations, but it tends to be much more tempered in reality.
|
|
#
¿
Dec 11, 2017 15:22
|
|
|
|
| # ¿ Apr 30, 2024 06:01 |
|
|
I bet they’re asking you if you know Puppet because some previous engineer wrote something using it and now they’re hamstrung by this system nobody else at the company knows.
|
|
#
¿
Dec 11, 2017 17:16
|
|