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 integration"
-
Looks like I'm getting fired on Wednesday :)
Long story:
*I add first unit tests to project.
*Boss adds new functionality and breaks all the tests so I can't compile and write more for what I'm working on.
*Boss is very fragile and cannot handle any comment that can possibly be taken as a slight against him.
Me: "I wanted to ask what our policy on unit tests is please? Because we haven't really said how we are treating unit tests, and everyone myself included is not thinking about them. I also haven't added tests when I fixed bugs and this time your changes broke the tests"
Boss 10 minutes later: "I want to speak to you in private".
Boss: "you are too forceful and direct. You said I should have added tests."
Me: "yeah but I didn't mean in a nasty way"
Boss getting louder and more aggressive: "You are too forceful"
Me: "I didn't mean it in a bad way"
Boss: "I didn't want to add tests for that!"
Me: "then why add any tests?"
Boss: "Fine we are not having this conversation now!"
*Boss storms out
I decided I can't speak to the guy about anything without upsetting him spoke to the manager before I quit because I can't work like this.
That resulted in a meeting with my boss, his boss and the head of HR where I ended up savaging him and told them I can't bring up anything as I can never tell if it will offend him and that I spend ages writing emails and trying to document communications because I just can never tell if I will upset him. Also that I cannot bring up any ideas because I can't tell if he will somehow get offended and that I can't even write code because if I change something he wrote at some point he will get angry.
My boss claims that I am extremely forceful and disrespectful and that I am constantly insulting him and his decisions.
We go back over a ton of shit and I refute everything he says. In the end I have to have a meeting with him on Wednesday where we either get things straight, he fires me or I quit.
I think at this point that our relationship is too fucked for him to be my team lead on a 6 man team.
Side note I keep bringing forth ideas because we have one database shared between 6 Devs, no pull requests (apart from mine and another new guy), no test driven development, no backlog, no team driven story pointing, no running tests before merging, no continuous integration setup, no integration tests, no build step on merge, no idea of if we are on track to our deadline other than his gut feeling, no actual unit tests backend - just integration with a test db, no enthusiasm to learn in the team and no hope.21 -
Imagine if a structural engineer whose bridge has collapsed and killed several people calls it a feature.
Imagine if that structural engineer made a mistake in the tensile strength of this or that type of bolt and shoved it under the rug as "won't fix".
Imagine that it's you who's relying on that bridge to commute every day. Would you use it, knowing that its QA might not have been very rigorous and could fail at any point in time?
Seriously, you developers have all kinds of fancy stuff like Continuous Integration, Agile development, pipelines, unit testing and some more buzzwords. So why is it that the bridges don't collapse, yet new critical security vulnerabilities caused by bad design, unfixed bugs etc appear every day?
Your actions have consequences. Maybe not for yourself but likely it will have on someone else who's relying on your software. And good QA instead of that whole stupid "move fast and break things" is imperative.
Software developers call themselves the same engineers as the structural engineer and the electrical engineer whose mistakes can kill people. I can't help but be utterly disappointed with the status quo in software development. Don't you carry the title of the engineer with pride? The pride that comes from the responsibility that your application creates?
I wish I'd taken the blue pill. I didn't want to know that software "engineering" was this bad, this insanity-inducing.
But more than anything, it surprises me that the world that relies so much on software hasn't collapsed in some incredible way yet, despite the quality of what's driving it.44 -
Me: *Installs travis*
Dev: oh what's travis?
Me: it's a continuous integration tool I wanna setup.
Dev: ... contin.... ?
Me: continuous integration, a tool that performs builds.
Dev: ah!, is it the new version of that deprecated tool we were using "client access"?
Me: ... no ... that's an authentication service that generates and stores oauth tokens. This is the continuous integration tool I told you about yesterday (and last week and the week before).
Dev: ... contin....
Me: ... con ........ continuous integration. It listens to branches on GitHub, downloads, builds, tests and then deploys the code.
Dev: ah ok ok, cool.
I would bet my monthly fucking salary he can not repeat what I said, tell me what oauth is, or explain what he's working on at the minute.
Jesus at this rate I'd bet my salary he can't tell me my name.7 -
IF LIVES DEPEND ON A SYSTEM
1. Code review, collaboration, and knowledge sharing (each hour of code review saves 33 hours of maintenance)
2. TDD (40% — 80% reduction in production bug density)
3. Daily continuous integration (large code merges are a major source of bugs)
4. Minimize developer interruptions (an interrupted task takes twice as long and contains twice as many defects)
5. Linting (catches many typo and undefined variable bugs that static types could catch, as well as a host of stylistic issues that correlate with bug creation, such as accidentally assigning when you meant to compare)
6. Reduce complexity & improve modularity -- complex code is harder to understand, test, and maintain
-Eric Elliott12 -
My devGoals for 2018:
- Build a RESTful API with NodeJS just for learning.
- Finish my first product (electronics sideproject).
- Convert more people to use CraftCMS or at least not use Joomla or WP.
- Get a raise.
- Add Continuous Integration to more projects.
- Add more unit testing where appropriate.
- Create and release a mobile app.
To be continued...
*playing to be continued meme sound*9 -
Find a place where management is able to handle some criticism.
I personally think Agile/Scrum is holy, and I don't mean "yeah we kind of do our own version of it", no, fucking do it by the book. The PM shouldn't assign estimates. Developers shouldn't receive bugfix requests from anyone other than the scrum master. The CTO can't be your scrum master... etc.
If a company can't answer the question "What were the points of feedback during the last retrospective(s), and how are those points being picked up?" -- Don't work there.
Many other things are optional in my opinion. I could work at a company without QA, without fruit baskets, table tennis, without Friday drinks. I could even live without git & continuous integration, just emailing patches to a patch integrator. I don't care.
But maintaining a safe bubble of serenity and sanity for devs to do their work in, that is an absolute must.
Also, option to WFH as much as wanted. Offices are nice for social bonding, but they kill productivity for me.6 -
A little late, and similar to other lovely ladies on here, but the greatest influencer for me is my husband.
He's always pushed me to learn more and be a better, cleaner coder. He taught me continuous integration, introduced me to the Atom editor, and showed me that my nerdy interests and choice of career can actually be quite attractive and not "intimidating" or "inappropriate” for a woman.
He's my go-to hackathon partner, my strictest code reviewer, and my life long teacher.
Ich liebe dich, mein Schatzelein! 😍7 -
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 -
There is nothing sexier than a well designed CI pipeline....i have wet dreams about that green check mark.3
-
"Who needs a staging server, test suites and continuous integration anyways haha"
-company i just joined6 -
How to get investors wet:
“My latest project utilizes the microservices architecture and is a mobile first, artificially intelligent blockchain making use of quantum computing, serverless architecture and uses coding and algorithms with big data. also devOps, continuous integration, IoT, Cybersecurity and Virtual Reality”
Doesn’t even need to make sense11 -
Programmers nowadays have to...
… write 100%-covering unit tests;
… set up continuous integration, linters, hinters, style checkers, …;
… follow style guides for every language;
… meet impossible deadlines;
… meet impossible management/customer/end user expectations;
… read through terrible code others made;
… read through terrible documentation others made;
… make terrible documentation themselves;
… fight with the IDE;
… fight with the build tools;
… deal with unreproducible crash reports coming in from everywhere;
… debug code written at 2am (by themselves AND others);
…
…
…
… KNOW HOW TO PROGRAM.6 -
Man, as much as I love reaping the benefits of Continuous Integration, I sure fucking despise having to set it up.
By the way, hi devRant!3 -
Just received a test for a job I'm interviewing for. I was interviewing for a C++ position. Practice test: Create an REST API using SpringBoot, Spring Data, document with Swagger and implement continuous integration testing.
To be fair, I also mentioned I'm fluent in Java. But I've never touched SpringBoot or done any backend webdev, since my intention was to never get near it.
Deadline: Sunday. Game on...4 -
devops guy: "Shut up, Perl is awesome. It is the best Swiss Army knife language."
I agree. Let us observe the architect in our metaphor, in charge of building our new building, insists on doing it ALL with a Swiss Army knife.
Yes, I agree with your comparison very very much.
(translation... I want to use Docker, a temporary db, and continuous integration. He wants to continue writing and reading tons of shit to a mess of JSON text files all over the place.)2 -
👍 https://github.com/auchenberg/...
"If you want your software to be adopted by Americans, good tests scores from the CI server are very important. Volkswagen uses a defeat device to detect when it's being tested in a CI server and will automatically reduce errors to an acceptable level for the tests to pass. This will allow you to spend less time worrying about testing and more time enjoying the good life as a trustful software developer."rant malice driven development devops task failed successfully volkswagen emissions continuous integration satire gone wrong troll10 -
First company:
- being sat at an office that didn't have chairs with proper back support. It would kill my back every day. Like sitting on a bar stool coding.
- not having access to basic resources (cafeteria, salary bonuses)
- being seriously underpaid ($200 under)
- not having an IT process pipeline (yeah, this is a huge one): no JIRA, no git, no VCS, no continuous integration, etc. I fucking spend 45% of the time fixing coding-unrelated shit.
Second company (very aggravating):
- dumb frontend bitch and privileged colleague who both kept telling me months on end to shut up and who wouldn't listen to my advice on anything, while my advice would actually help the company advance in productive ways. The key here is being told to shut up while stagnating. i.e. dead end job.
- people advancing in the company based on nepotism and favoritism, based on having tits and ass, rather than skills and independence.
- pointlessssssssss meetings where decisions are made solely based on the opinion of Mr. favorite senior dev. The rest just sits there like a bunch of sad saps and yay-nodders. Incompetent PO's who "would like to hear your input" but then when you give it, they completely dismiss you.
- pointlessssssssss monthly meetings with stakeholders, where the dev teams do nothing but clash and act like pussies in front of the PM just to get in his favor, but behind scenes continue to make the same mistakes and telling the CEO everything is fine. Goodness, how can it get more unproductive.
- completely antisocial and nepotistic 'colleagues' who won't even talk to you, let alone smile at you or be friendly. You saying good morning and them pretending you're vapor that doesn't exist. Go go company atmosphere! Especially during lunch, those are the worst times. Imagine sitting at lunch where everyone looks like you killed their dog and the rest is huddled up in little high school groups.
What else? The incessant and pointless smalltalk that makes me want to bang my head against the wall. Talking about dogs, kids, what show was on tv last night. The fuck man, do you have a brain?!
Third company:
- HR bitches who think they are the shit and developers are antisocial, helpless misfits, but they work with computers and they don't even fucking know what a status bar is! The irony!
- forced socializing and stigmatization for the opposite. Imagine coming into a company and you don't say good morning. Should that be a problem? No. Instead, everyone starts dogging on you and hating you just because you didn't smile in their faces and said: hiiiiiiiiiiii how did you sleep? Did you feed your dog? Fuck you.
Elliot (Mr. Robot): "Wouldn't it be awesome if there was a mute button for life?" -boop, boop, boop, boop...- Ahh.. there.. that's much better."
- CEO's sucking up to you but when it comes to salary increase, they say shit like: "Ahhh ya know, it's kinda difficult." Yet another dead end job.2 -
So I am finally plunging into continuous integration. If I make one more deploy script mistake, I've lost enough time to merit having learned a better solution than bash scripting calling git and rhc and py files I wrote. I have failing tests that are failing because they weren't updated after the million and a half urgent changes in the past 2 months, so it's time to act like I am a TDD fanatic and write the tests correctly. So much work. All from me listening to the constant req changes, listening to the urgency, letting non-devs get under my skin if you will. I'm optimistic in all the wrong places - I think I can write that by end of day let's try it. I'm lazy in the wrong places - I think that I can write that test later, because all I changed was XYZ (which took all night but I said I'd get it as close as possible didn't I?). And I think these handful of bash scripts are good enough to make sure I run tests? But remember, I didn't write the tests or I didn't go back and update them. Or the tests that fail, I'm too lazy. And so much of the tests, I would need to use, idk selenium for, and damnit if I really don't want to dig for element IDs to wait for every time I need an AJAX call.
Okay wow, I really did rant here. And discredited myself a bit lol I need to ignore the wrong lazy and embrace the right lazy. Protect myself from myself and from contributors. It really is, up to me now, to rescue myself from my bad habits. Bad habits perpetuated by clients urgency every day, to change things, that should have been finalized in November if we wanted a stable flipping system in January. It feels like the blind (client) leading the blind (me, when I do dumb shit like rush features out the door half tested).
Anyway all this came out, because I have been reading about continuous integration and stumbled upon this quote. And thought someone might laugh at the anachronism like I did2 -
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 -
I hate the fact that our university is hiring ex-developers from the year 1990-2000 to teach us. They are knowledgeable about many stuff like datastructures and algorithms, but when they force a project on us where we have to use some new tech, the students become the teachers. Heck, one of the requirements of the project was to set up a continuous integration server and we had to explain to them that we needed a server and how git was part of it. (classmate even had to explain how git worked to them).
I know that adapting and learning stuff yourself is part of the education, but why are we the ones who should explain the stuff we MUST know to get our degree to the teachers who are supposed to actually, in my opinon, be experts and knowledgable in what we have to know and learn..2 -
Stop wasting time setting up continuous integration environment and get on with real work.
2 days later: why aren't we using continuous integration, the plan says we have to. -
My boss told me to dismantle the continuous integration server for me project and document how to do those manually.1
-
I need to convert lots and lots of lengthy hard-coded entities into backend objects, as I'm tired of pushing new commits every time something superficial needs to change.
Also, I need to figure out continuous integration. The guy who was going to help with that just left the company, and I was using his eventual forthcoming help as an excuse not to take responsibility for learning about it myself.
I need to learn golang and start converting some code to it, to see if the performance compares to the perl that's currently in place. Perl is brilliant, but aside from me, only old people know it, at my office. That definitely creates a longterm supportability issue.2 -
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 -
That feel when your job's codebase is well-maintained, extensively covered with unit, integration and full product automated tests, everything is run through continuous integration, and every change has to be scrutinized and reviewed by multiple people; so you have barely anything to devRant about :(
-
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 HATE the idea of only releasing on pre-determined schedules despite work being completed and just waiting for that day to arrive.
I'm a co-founder of a small software company. We have partnered with another particular company that also writes software. Some of our clients have access to paid content of that company's services through our application.
Every once in a while, our clients will report issues with that company's service to us, because they access it through our application. They think it's our issue.
We then pass the report on to the partner company, telling them that their stuff is broken. Their reply goes like this:
"Ok. We'll get the bug fix scheduled, and we'll release it next Thursday."
"Next Thursday? The issue is now, they can't use the service."
"That's our scheduled release date."
O.M.G.
We voluntarily walked away from our safe, cushy jobs working for other people, taking enormous pay cuts to start this company. Now, we're 6+ years in, disrupting established fat-and-happy competitors in this space. I GUARANTEE you that if we had that same attitude, we would have been absolutely obliterated early on.
We are quick. Guided by kanban boards, our suite of unit tests and integration tests is vast and kick-ass. With continuous integration and the click of a button we know if we broke something or if the piece we're working on is ready to be pushed to production, IMMEDIATELY. Our "release schedule" is when the damn thing is complete.
It isn't all bad. Our integration with them has been beneficial for both of us. I just loathe their snail's pace which negatively affects our mutual customers. It can make us look bad, and we can do nothing about it.
Blah.3 -
Two (2) senior developers and one (1) senior tester left our team and I am left with two (2) Java legacy applications that are hard to maintain. Here is a list of things I hate about these old webapps (let's call them app A and B):
1. App A depends on 80% web services. If one web service for a product or warehouse goes down, work flow is impeded while prod support team checks with the core services team for repair
2. App B is a maven project with multiple modules dependent on libraries that are dependent on company's internal libraries. So if we want to upgrade to OpenJdk 9 and up, the project will definitely produce a lot of errors due to deprecated/unsupported codes
3. App A is dependent on Tibco and I have no experience on that
4. App B's continuous integration build tool is Jenkins and the jobs that build it has a shell script that wasn't updated during the tech upgrade enhancement. The previous developer who did the knowledge transfer to me didn't tell me about this (it should be considered a defect on her part but she already resigned)
5. App A when loaded in eclipse IDE is a pain to work with since it is only allowed to build a war file using ant. I have to lookup in quick search instead of calling shortcuts (call hierarchy) because the project wasn't compiled via eclipse.
6. It's impossible to debug app A because of #5
7. Both applications have high priority and complex enhancements and I have no other teammates to help me
8. You never know what else can go wrong anytime1 -
Killing people is bad. But, there should be a law to allow killing people who don't write proper unit tests for their code. And also those "team leaders" who approve and merge code without unit tests.
Little backstory. Starts with a question.
What is the most critical part of a quoting tool (tool for resellers to set discounts and margins and create quotations)? The calculations, right?
If one formula is incorrect in one use case, people lose real money. This is the component which the user should be able to trust 100%. Right?
Okay. So this team was supposed to create a calculation engine to support all these calculations. The development was done, and the system was given to the QA team. For the last two months, the QA team finds bugs and assigns those to the development team and the development team fix those and assigns it back to the QA team. But then the QA team realizes that something else has been broken, a different calculation.
Upon investigation, today, I found out that the developers did not write a single unit test for the entire engine. There are at least 2000 different test cases involving the formulas and the QA team was doing all of that manually.
Now, Our continuous integration tool mandates coverage of 75%. What the developer did was to write a dummy test case, so that the entire code was covered.
I really really really really really think that developers should write unit tests, and proper unit tests, for each of the code lines (or, “logical blocks of code”) they write.20 -
I have officially decided to use CI (Jenkins) at work because "apt-get update && apt-get upgrade -y && composer self-update && composer update && npm update -g && npm update && bower install --allow-root && gulp" after a pull doesn't seem healthy 😂2
-
We had a project where we had to code in c# and setup a continuous integration server and create some tests for our application.
Our teacher asked:"Are you guys using junit?
He was serious. -
I'm at this magnificent company, working scrum, doing continuous integration which is really very cool. But although the features we develop are really nice it is sooooooo boring.
One of our team members emphasized that we should not pick up new stories if we haven't finished previous stories yet. I agree to some extent but think it is ok to pick up new stories if you have nothing to do. But we may not.
So, here I am now. Literally waiting for the day to pass. This sucks sooooo much!
I'm a hard worker and perform at my best under pressure with many things to do. Now, I just deployed one tiny little story today. I can do much much more. I feel so useless and cannot believe that my client pays so much just for me being at the office. And occasionally clicking a button and writing a line of code. This is so fucked up.5 -
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 -
PM: "We would like our automated testing / continuous integration in AWS"
Me: *Army crawling towards Jenkins with my last dying breath*3 -
Every day I ask myself at least 5 (not too difficult) questions about programming (for instance "Can I compile Java in runtime?")
If I don't know them - I find their answer somewhere
It is like continuous integration, but with my knowledge - small portions of info are saved well in my brains)) -
How often does this happen to you?
Just updated our continuous integration and for some reason the BuildAgents, who update independently, just kept failing to update.
Tried every trick in the book, debugged everything.
Kept complaining about being unable to delete files, frigging Windows file system being an idiot as always...
Was about to give up and migrate everything to a fresh system until I realized...
*reboot*
Ah, it works now!
... Why does it always take me so long to realize that's an option!?3 -
!rant
For the past weeks I've been reading about continuous integration and today I finally decide to dive into Gitlab-CI. After a couple hours I finally managed to have a working pipeline for one of my project using a self-hosted runner and holly shit that was satisfying. Now I just don't see myself not using this in the future -
A home hosted build server for continuous integration is always crap and a blocker for everyone. If you don’t have 5(yes, five) full time admins/devops to support that, forget about building the infrastucture yourself. There are companies whose business is to provide CI as a service, why do you think you can beat them with your crappy Jenkins installation?
I’ve seen a 200 company failing with 2 people. I’ve seen another one completely failing, because the admins didn’t know what CI meant, and a small one failing with 0.5. The only place where it kind of worked used Gitlab. -
!rant
What a great feeling when you push a big bunch of changes and CI makes it over the biggest hurdle (lint and test). Time for a fresh cup o' coffee while the build finishes. -
please i need your advice :)
I need to reform a service that offers legal advice and thus serves around 5000 Microsoft Word legal advice documents for the end user and every year there are 200 more documents created and published and changed manually.
So i had this idea to use a CMS, Git and continuous integration for
- automatic spell checking
- automatic assigning the copy text to translation bureaus, and get translations back.
- version control the texts and translations.
- document generation in multiple formats
- checking the text flow in the document (no overflown text)
- Checking for accessibility for the handy caped
- Deploying it on the Website
Do you think this is feasible? Can something that was made for code also be used to handle copy text documents? In my head this would save so much work but i'm no expert in CI/CD.
Thank you for your advice!8 -
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 ! -
Continuous integration makes things easier, but it looks difficult to get started with for a beginner.
https://cloudways.com/blog/... -
I have a spare, fully functioning i5 CPU with 8GBs of RAM.
I was thinking of converting it into a continuous integration server with GitLab.
What would you guys do with it?7 -
Does the company you work at have a CI/CD pipeline (Continuous Integration/Continuous Delivery, e.g. with Octopus Deploy)?
Sometimes it surprises me how many companies don't have this..10 -
Hi everyone, I’m trying to wrap my head around dev ops but struggling with the whole continuous integration workflow. From my understanding it goes something like the following:
1. pushing a change to some repository (git)
2. Some tool (Jenkins) tries to build it and if it’s succeed, creates a image /container (docker).
These containers are hosted on some cloud service (aws)
Some workflow, walkthrough, or examples would be very appreciate.7 -
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 -
Murphy's Law of Continuous Integration: If your code finally unbreaks the build, then the build will break because the PGP Key server didn't respond in time.
-
I work on a larger team where we do continuous integration so there is a high probability people will be working on the same files for different features. As a result, one of the best feelings is grabbing the latest files and not having to diff first thing in the morning.
-
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
-
Guys, about Continuous Integration/Delivery using SVN as repo... What is the best approach? It would be nice if it could trigger the files that should come to prod by commit message or something like that...
Thank you.3 -
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 -
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!