Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "continuous deployment"
-
Feeling like I've gone back in time about 15 years!
Just told my CTO about various improvements we could make to the development process. Things like git, continuous delivery, agile project management apps such as Jira, task management such as Gulp, etc.
His response - "never heard of them. I bet they'll pass in a few months. Just another round of fads".undefined continuous deployment git fml i hate my job anyone hiring time travel gulp agile efficiency7 -
I've been fired today and somehow it was an relief :)
As I know that I am pretty much the only one who knows how the infrastructure works and I am the only one who actively tried to get the company to a better level of coding (tests, code reviews, proper deployment / continuous integration,...) It somehow feels like that gif.10 -
When good developers are afraid of refactoring and adding new classes is something to be feared, you need to rethink your architecture.
In fact, if there's ever that "dark corner" of code that no-one likes to work with, you've got to fix it.
It's like continuous deployment. We do it often because it's hard and having to deploy regularly forces us to make it easier.2 -
procrastinating by getting drunk since 11:00 AM, and writing specs for my (hypothetical) language/os/platform.
feeling righteous retribution because the client made me be stressed for 3 hours due to an issue that THEY caused but for 3 hours the only info I had was "there's a critical blocker issue and we're convinced YOU caused it"
well... no... i did NOT cause the fact that you UPGRADED PHP DURING THE WEEKEND BEFORE MONDAY'S PRESENTATION TO CLIENT (while waiting for an urgent commit from me).
seriously.
also, germans. i've heard many times from other people that they're... basically racist towards us (slavic nations), thinking of us as untermensch, coal-miner peons, but I didn't realize their passive-aggressive covertly smug demanding attitude is due to this, I just assumed it's a reaction to me being incompetent.
so yesterday when we finished the call (in preparation for which I tried to switch to their "client demonstration" branch since that's where the error was, and I wanted a headstart on fixing it, ended up in a place that my today's whole-day task should be "rebuilding the DB into working condition", because there's about 10 "core" sql scripts in two different folders, which need to be run (in a very specific order, of course, which readme tells you, but what it tells you has been outdated at least for 3 months, of course), and
...THE MAIN CORE SCRIPT THAT IS THE FIRST TO RUN, THAT CREATES THE DB schema, HAS THREE SYNTAX-LEVEL typos which fail it mid-way...
...the joys of continuous deployment via scripts, I guess? I would love to challenge any person from them to screenshare to me, manual deployment of the current version from zero, and I would be willing to give the person 20% of my monthly salary if they would be able to do it within 20 minutes.
but... well...
the point is, i should be doing not entirely bullshit stuff.
but yesterday's 6 hours of being in "at full attention because it seems we fucked up" totally convinced me, that today I'm taking a break.
So I'm gonna go buy another 3 beers and continue writing the specs of my dream language/os/platform.19 -
Tl;Dr Im the one of the few in my area that sees sftping as the prod service account shouldn't be a deployment process. And the ONLY ONE THAT CARES THAT THIS IS GONNA BREAK A BUNCH OF SHIT AT SOME POINT.
The non tl;dr:
For a whole year I've been trying to convince my area that sshing as the production service account is not the proper way to deploy and/or develop batch code. My area (my team and 3 sister teams) have no concept of using version control for our various Unix components (shell scripts and configuration files) that our CRITICAL for our teams ongoing success. Most develop in a "prodqa like" system and the remainder straight in production. Those that develop straight in prodqa have no "test" deployment so when they ssh files straight to actual production. Our area has no concept of continuous integration and automated build checking. There is no "test cases", no "systems testing" or "regression testing". No gate checks for changing production are enforced. There is a standing "approved" deployment process by the enterprise (my company is Whyyyyyyyyyy bigger than my area ) but no one uses it. In fact idk anyone in my area who knows HOW to deploy using the official deployment method. Yes, there is privileged access management on the service account. Yes the managers gets notified everytime someone accesses the privileged production account. The managers don't see fixing this as a priority. In fact I think I've only talk to ONE other person in my area who truly understands how terrible it is that we have full production change access on a daily basis. Ive brought this up so many times and so many times nothing has been done and I've tried to get it changed yet nothing has happened and I'm just SO FUCKING SICK that no one sees how big of a deal this. I mean, overall I live the area I work in, I love the people, yet this one glaring deficiency causes me so much fucking stress cause it's so fucking simple to fix.
We even have an newer enterprise deployment. Method leveraging a product called "urban code deploy" (ucd) to deploy a git repository. JUST FUCKING GIT WITH THE PROGRAM!!!!..... IT WAS RELEASED FUCKING 12 YEARS AGO......
Please..... Please..... I just want my otherwise normally awesome team to understand the importance and benefits of version control and approved/revertable deployments2 -
What the fck is CI/CD?!! Hmmm 🤔 I don’t know, but it sounds trendy so might as well pretend to know it to sound cool.13
-
I am amazed at human stupidity.
I always enjoyed the idea of DevOps: to use virtual machines and constant integration in order to avoid errors and free the developers of hard-to-setup environments and somehow-it-works compilations.
I am amazed how [company I used to work for] managed to turn this into a nightmare.
Just imagine: silent forests, the smell of flowers, no developer trust to the point your devs can’t either make docker environments cause reasons nor they can access your actual machines programmatically because they are filthy peasants, forcing them to do everything manually: every deployment will be a frustrating editing process which takes up to an hour, but here lies the trick... it will still have continuous integration... or better: every feature will be deployed as if it was a release.
The true peak of illumination:
Turning a tool into a disease.
Take a sip of tea, manager... you deserve it.
Just thought about this job because I keep being tempted to just start my own company. The more I think about it, the less being employed makes sense, given my end goal.2 -
The conversations that come across my DevOps desk on a monthly basis.... These have come into my care via Slack, Email, Jira Tickets, PagerDuty alerts, text messages, GitHub PR Reviews, and phone calls. I spend most of my day just trying to log the work I'm being asked to do.
From Random People:
* Employee <A> and Contractor <B> are starting today. Please provision all 19 of their required accounts.
* Oh, they actually started yesterday, please hurry on this request.
From Engineers:
* The database is failing. Why?
* The read-only replica isn't accepting writes. Can you fix this?
* We have this new project we're starting and we need you to set up continuous integration, deployment, write our unit tests, define an integration test strategy, tell us how to mock every call to everything. We'll need several thousand dollars in AWS resources that we've barely defined. Can you define what AWS resources we need?
* We didn't like your definition of AWS resources, so we came up with our own. We're also going to need you to rearchitect the networking to support our single typescript API.
* The VPN is down and nobody can do any work because you locked us all out of connecting directly over SSH from home. Please unblock my home IP.
* Oh, looks like my VPN password expired. How do I reset my VPN password?
* My GitHub account doesn't have access to this repo. Please make my PR for me.
* Can you tell me how to run this app's test suite?
* CI system failed a build. Why?
* App doesn't send logs to the logging platform. Please tell me why.
* How do I add logging statements to my app?
* Why would I need a logging library, can't you just understand why my app doesn't need to waste my time with logs?
From Various 3rd party vendors:
* <X> application changed their license terms. How much do you really want to pay us now?
From Management:
* <X> left the company, and he was working on these tasks that seem closely related to your work. Here are the 3 GitHub Repos you now own.
* Why is our AWS bill so high? I need you to lower our bill by tomorrow. Preferably by 10k-20k monthly. Thanks.
* Please send this month's plan for DevOps work.
* Please don't do anything on your plan.
* Here's your actual new plan for the month.
* Please also do these 10 interruptions-which-became-epic-projects
From AWS:
* Dear AWS Admin, 17 instances need to be rebooted. Please do so by tomorrow.
* Dear AWS Admin, 3 user accounts saw suspicious activity. Please confirm these were actually you.
* Dear AWS Admin, you need to relaunch every one of your instances into a new VPC within the next year.
* Dear AWS Admin, Your app was suspiciously accessing XYZ, which is a violation of our terms of service. You have 24 hours to address this before we delete your AWS account.
Finally, From Management:
* Please provide management with updates, nobody knows what you do.
From me:
Please pay me more. Please give me a team to assist so I'm not a team of one. Also, my wife is asking me to look for a new job, and she's not wrong. Just saying.3 -
So, right now we upload production code by means of FTP.
I said it would be better to use continuous deployment using Docker, but they said it was overkill (I work at a small company).
Because manually uploading by means of FTP is so much better right...6 -
Every time we have a release, "Release Engineering" stops building our test environments from master. I've been preaching Continuous Deployment for months and here we are with the most broken system. The build actually builds all test environments AND prod from the same branch because "it's easier" for "Release Engineering". So now I have to wait for the code freeze on release and hope RE doesn't fuck up and deploy an untested branch to prod... AND hope we're given enough time to test and debug the next release since we can't right now...1
-
For all the effort it takes to setup CI/CD it's totally worth it. My god this is marvellous I've wasted over 40 build minutes already just to see a spinner spin until it turns green :-D2
-
Finally successfully set up continuous deployment on a personal project. Ever, really. And on one of my few open source applications. Destiny Clan Manager... it uses the Bungie API to help you manage your clan on Destiny 2. Neat little weekend project. Made some changes today, and thought... why not. It's all using Azure.
If you're interested: https://github.com/demortes/DCM2 -
Auto Login feature enables itself when a certain config flag is present - the app will login as an admin without requiring username or password.
I pray to the Continuous Deployment monsters that the config setting never gets copied to production by mistake.2 -
So we now do continuous deployment to a development environment. Once a PR gets merged it gets deployed there. We then have to manually deploy to staging every so often.
We did this because QA wined that the Dev was constantly breaking Staging, when we contentiously deployed to that.
So now we have a staging instance that is always behind. Which isn't big deal, because its supposed to be stable right?
Well now the stupid fucking QA team is always making mountains of tickets and noise for stuff that is already fixed on the development instance.
Fucking shit that they message me about, or have to call me about. "Hey let me tell me about this thing I found." And then I'm like I already fixed that thing last week.
So it seems to be wasting everyone time to not just CDCI into staging. I have to wait weeks to retest my bugs on staging. To make sure that some other stupid fuckeshir on my team didn't undo or break my fucking fix. Shit keeps getting kicked out of QA Review. Fuck. lol.
Then there like I can update the thing on the database through the front end tool. Well tough shit buddy, your going to have to wait a week unti next staging deployment to see if that tool is fixed. This is your fault for fucking up our pure CDCI with your ideas. Now everything takes longer for everyody.
To sum things up. Some dumb bug makes it into the manual staging deployment and gets fixed an hour later. Doesn't get deployed until next fucking week. QA makes a bunch of noise about it. A thing that is fixed and in the pipe-line.
Also a dumb fucking bug will make it into staging, lets say a critical front-end back office tool that needs to send numbers to the backend, they send a fucking string instead of a number and break it. Now we have to redeploy the tool and backend to staging because there related. Then if we deploy backend we have to deploy the client facing site too. since it also depends on backend.
Its a fucking hassle.
Now if the fucking DevOps guy could do his job, and make a god-damn deploy button for all the staging servers that would be great.1 -
The integration of technologies project I have this year. Not yet finished but I already learned a lot of very cool stuff.
First, I learned a new programming language + framework (Ruby on Rails)
Second, for the first time, I implemented a continuous deployment pipeline with Capistrano and Travis ci.
Third, first time I programmed a Restful API.
And more cool stuff coming up ! :D
I freaking love learning ! -
Yesterday we had discussion on with developers about continuous deployment. When I asked one of the senior developers why they can't uncommit what commits you made to integration branch and which led to integration test failures. He said it's against the basic philosophy of git to uncommit... I don't know how git works...but seriously you can't use previous version of code or can't uncommit??6
-
I've been thinking about ways to improve my workflow for my personal projects.
I'm getting to grips with continuous integration and deployment etc, but I want to also automate, or at least semi automate my changeling generation.
I don't like using any sort of gitlog shenanigans, and I quite like the girls way of doing it.
I.e you run a script which generates a yaml file with your changeling info in, and then all the files are written into the changelog.md file.
How do you guys handle the generation of your changelings?3 -
What is the best approach for Continuous Integration / Continuous Delivery/Deployment? I'm using SVN as code repository and I need to identify the files that goes to Test/QA env. and the ones that goes do Prod env. (by Commit message or something else) via sFTP.
Any help would be appreciated. Already tested Jenkins, GoCD and Jetbrains Teamcity.1 -
Ok. Wtf?!?
Our platform architect gives a damn about continuous delivery.
Today I asked the architects for help, because bamboo is not able to trigger a deployment plan by changes in repository branch pattern release/x.x.x.
He cancelled my question with the statement "if we have the Kubernetes environment, we have more valuable things to work on".
Generally CD is no rocket-science and it is achievable with reasonable effort!