|
Vulture Culture posted:I'm getting really, seriously twitchy at this particular use of the word "DevOps". These days it's just a catchphrase used to describe a style of engineering that combines developer and operations type roles. There are associated best practices and technologies. Like Orchestration, Containerization, CI/CD, etc. There are also plenty of shops that describe themselves as devops and the reality is that they fired their operations team and make their devs reboot servers. So really, his use of the word isn't that out of bounds, but he should have been asking about using small scale orchestration.
|
#
?
Feb 21, 2018 19:28
|
|
|
|
| # ? May 16, 2024 09:13 |
|
|
It’s a real hoot to interview for a DevOps position only to find out they want something completely different than what you have. It’s getting to the point of “Engineer” now. Everybody’s definition is wildly different.
|
|
#
?
Feb 21, 2018 20:10
|
|
|
Warbird posted:It’s a real hoot to interview for a DevOps position only to find out they want something completely different than what you have. It’s getting to the point of “Engineer” now. Everybody’s definition is wildly different. Current job is a DevOps position and it's my first time not in a pure software developer role. It's always been my opinion that all software devs should understand how their software is built and deployed in production. DevOps shouldn't be a black box.
|
|
#
?
Feb 21, 2018 20:12
|
|
|
DevOps at my current workplace is pretty much just Ops. I’m mostly doing automation and being the middle man for people that need environments for the project. It’s a bit of a pain as most places in the area more closely associate it with AWS/Azure and/or CI. I can read up on it all day, but I’m somewhat concerned about my finding something else when/if this contract ends.
|
|
#
?
Feb 21, 2018 20:17
|
|
|
My title is "Cloud DevOps Engineer", which is just gobbleygook. I basically do infrastructure-level automation / codification / etc and help other groups move projects to The Butt without doing a lift-and-shift. The crappy part is the teams that need my groups help to move and re-architect are the teams that are so unskilled they shouldn't be involved / doing it at all. And most of that stuff is vendor trash. There's really only like 2 "real" software projects our group is looped into the cycle of.
|
|
#
?
Feb 21, 2018 20:27
|
|
|
Rocko Bonaparte posted:The big thing here is somebody would want to add a step towards a regression, but we don't want unrelated commits that don't even have the matching code to fail. I expect the incompatible code to get through because it has already happened two of three times we did this. We were about to start adding more steps more often, and I don't want it to become a game of us having to get together and turn our keys at the same time. You absolutely don't want to be trying to synchronise the manual parts of the process in order to make the automatic parts work properly. I think TeamCity leads you into a trap here, because it has so many options for build runner steps that it's far too easy to add everything as a new step, but since the TeamCity config doesn't mirror the branches on your source control you end up breaking all of the branches every time you make a config change. The only way to keep your sanity is to keep the steps in TeamCity as high level as you possibly can, i.e. 1. Build Project (by running a build script in the same repo as the code, so your build config always matches the code it's building no matter what), 2. Run Regression. Here you have 2 options, most likely you keep the regression script in the same repo as well together with the build script (so again it's always correct for any given build regardless of how old the branch is or what has been changed). If you have developers who like to make lots of tiny commits that only ever change one thing and push them continuously then you might have to train them to squash the commits or put up with breaking the build every time they don't update the regression script in lockstep. The other way is to keep the regression suite in a different repo, in which case your code repo needs to have some config file which defines the version of the build script that it depends on. That might just be a case of using the commit hash from the regression repo, or you can get more advanced and use nuget packages or whatever depending on how complicated your regression suite is.
|
|
#
?
Feb 21, 2018 21:57
|
|
|
There is a great need for people that know what they’re doing in most organizations because most places over time just plain rot on the operations side because it’s typically a cost center and leads to horrible attrition rates. One place I’m familiar with wound up trying to aggressively recruit kids just out of school to replace senior ops engineers that were leaving by the droves and even the contractors were not biting.
|
|
#
?
Feb 21, 2018 22:51
|
|
|
I feel like DevOps just means we wait for the OpenShift admins to fix our broken pods instead of the sysadmins to fix our servers. Where’s my magical future dammit?
|
|
#
?
Feb 22, 2018 01:07
|
|
|
VMWare has poo poo the bed at the workplace and we've been unable to spin up Windows VMs for close to a month now. Current lead times now that it is kinda working are longer that it would be to get a physical server in place. Yaaaaaaaay.
|
|
#
?
Feb 22, 2018 01:40
|
|
|
smackfu posted:I feel like DevOps just means we wait for the OpenShift admins to fix our broken pods instead of the sysadmins to fix our servers. Where’s my magical future dammit? If your “devops” use openshift, they are the trash. Also with k8s I’d make you all fix your own poo poo. poo poo I don’t even go on call anymore. Edit: the sysadmin thread had me in a combative mood. I think that there are legit draw backs to openshift that makes it less optimal then just using regular kubernetes. They subvert more then a few workflows and endpoints behind what I think is worse abstractions. freeasinbeer fucked around with this message at 02:00 on Feb 22, 2018 |
|
#
?
Feb 22, 2018 01:57
|
|
|
Warbird posted:VMWare has poo poo the bed at the workplace and we've been unable to spin up Windows VMs for close to a month now. Current lead times now that it is kinda working are longer that it would be to get a physical server in place. Yaaaaaaaay. I'm not even sure I can guess at what level of incompetence this requires. Also, it's VMware. It looks weird the other way and generally shows you don't have familiarity with what you're talking about.
|
|
#
?
Feb 22, 2018 06:14
|
|
|
For the longest time VMware’s internal IT didn’t use any virtualization (as of 2011). Why? More management headaches than it’s worth for systems that run software provided by vendors and packaged up nicely rather than developed in-house - the precise scenario that most VMware customers use vSphere for.
|
|
#
?
Feb 22, 2018 16:39
|
|
|
edit: oh crap i was pages back
|
|
#
?
Feb 22, 2018 17:35
|
|
|
In a low stakes, low intensity, onprem existing puppet managed environment is the basic docker puppet module a reasonable way to manage a handful of containers?
|
|
#
?
Feb 22, 2018 17:46
|
|
|
Internet Explorer posted:Also, it's VMware. It looks weird the other way and generally shows you don't have familiarity with what you're talking about. My understanding is that it was something with load balancers compounding with some other issues. My team isn’t involved with any of that, so who even knows. I just want some test/dev environments and lord knows that isn’t happening any time soon.
|
|
#
?
Feb 22, 2018 18:01
|
|
|
freeasinbeer posted:If your “devops” use openshift, they are the trash. Yeah, I'm on call for things like 'something is wrong with the ingresses or kube-router'. "My service is broken" is solidly Not My Problem.  except DevOps.
|
|
#
?
Feb 22, 2018 18:03
|
|
|
PCjr sidecar posted:In a low stakes, low intensity, onprem existing puppet managed environment is the basic docker puppet module a reasonable way to manage a handful of containers? It's fine in an appropriately low intensity environment, but Docker is utter trash at every turn, and I would recommend using literally anything to orchestrate scheduling other than some puppet module that runs docker commands (or unit/service files that do the same).
|
|
#
?
Feb 22, 2018 18:05
|
|
|
Are there vendor-agnostic certifications for DevOps? I might take the AWS Associate ones within the year but I'm wondering if there are options that don't lock you into a specific vendor. Or would AWS be good enough for most companies? I found this from the Linux Professional Institute and it looks promising... Any thoughts?
|
|
#
?
Mar 2, 2018 04:34
|
|
|
Are there any CI systems that people have had good success with? I'm looking at alternatives to Jenkins that we can run on-prem (some projects have this as a requirement). I have an email out to the Travis CI guys for enterprise pricing; but I'm also looking at GoCD; what other options are reasonable for on-prem work?
|
|
#
?
Mar 9, 2018 02:38
|
|
|
Walked posted:Are there any CI systems that people have had good success with? I'm looking at alternatives to Jenkins that we can run on-prem (some projects have this as a requirement). What's wrong with Jenkins?
|
|
#
?
Mar 9, 2018 02:47
|
|
|
Concourse I guess. But really. Run jenkins
|
|
#
?
Mar 9, 2018 02:58
|
|
|
Concourse is literally the worst software I've ever used. It's not that it's breaks, but it's insanely opinionated and built around incredibly strange and awful abstractions. You can't parameterize builds, you can't rebuild builds, you can't tell where a build is running without curling poo poo in your job. Build config lives 50% in your repo and 50% in concourse. Running a command takes like 4 different files of config.
|
|
#
?
Mar 9, 2018 04:33
|
|
|
I worked at a place once that used TeamCity, I didn't have any major complaints.
|
|
#
?
Mar 9, 2018 04:51
|
|
|
Basically Jenkins is what we keep coming back to but we hate it. Once I am back from vacation I am going to just use it as a shim for cloudbuilder. The problem I have with Jenkins is that we already do all our builds in docker, so something like Travis, Concourse or drone make a lot of sense to us where we can define a super simple set of steps in yaml that wrap what the devs are doing already.
|
|
#
?
Mar 9, 2018 04:53
|
|
|
I would really like to see a clone of Jenkins not written in Java, plus Jenkinsfile support in a language other than groovy. We've used bamboo and Jenkins primarily. And one guy used team city, which was just dead reliable. But 95% of everything I've seen was running Jenkins.
|
|
#
?
Mar 9, 2018 05:01
|
|
|
Mao Zedong Thot posted:Concourse is literally the worst software I've ever used. It's not that it's breaks, but it's insanely opinionated and built around incredibly strange and awful abstractions. You can't parameterize builds, you can't rebuild builds, you can't tell where a build is running without curling poo poo in your job. Build config lives 50% in your repo and 50% in concourse. Running a command takes like 4 different files of config. 100% agree but he wanted alternatives.
|
|
#
?
Mar 9, 2018 05:06
|
|
|
Hadlock posted:I would really like to see a clone of Jenkins not written in Java, plus Jenkinsfile support in a language other than groovy. Do you have a wishlist for such a system? The language is written in I doubt matters very much, though probably support for scripts/instructions written in many languages would be a bonus. If you can outline a set of needed features, i can guarantee that there are developers out there able and willing to implement said features, even if it would mean to fork an existing system (jenkins....).
|
|
#
?
Mar 9, 2018 05:39
|
|
|
TeamCity is very reliable and works well for us. Depends on what you’re building at the end of the day though.
|
|
#
?
Mar 9, 2018 05:48
|
|
|
Has anyone here used Buildbot, in a larger setting than with 3 developers? I've heard good things about it, but only at small scale.
|
|
#
?
Mar 9, 2018 12:31
|
|
|
Methanar posted:What's wrong with Jenkins? Just doing my due diligence; I'm our cloud services 'lead' but have started taking on a role of supporting some development teams as well - a couple of which are new contracts/projects without a CI/CD platform in place yet. So I'm just making sure that we're having this conversation - even if it's super brief - before it's too late to even discuss.
|
|
#
?
Mar 9, 2018 15:53
|
|
|
Hadlock posted:I would really like to see a clone of Jenkins not written in Java, plus Jenkinsfile support in a language other than groovy. I would love for Jenkins to support the full Groovy language and not sandbox poo poo in weird ways.
|
|
#
?
Mar 9, 2018 16:50
|
|
|
poemdexter posted:I would love for Jenkins to support the full Groovy language and not sandbox poo poo in weird ways. I'm currently developing a shared pipeline library for some Jenkins stuff and I loving hate it. You end up with @NonCPS all over the place because of its weird sandboxing poo poo, they want you to use declarative syntax because it's new and better but it doesn't support anything mildly complicated, and the only way to test changes that can't be unit tested is to commit and push it and run a job on Jenkins because god forbid they support loading the library from anything besides source control, so you end up with a hundred commit messages like "gently caress it let's try putting this here." Seriously just support rake libraries or something.
|
|
#
?
Mar 9, 2018 17:14
|
|
|
Erwin posted:I'm currently developing a shared pipeline library for some Jenkins stuff and I loving hate it. You end up with @NonCPS all over the place because of its weird sandboxing poo poo, they want you to use declarative syntax because it's new and better but it doesn't support anything mildly complicated, and the only way to test changes that can't be unit tested is to commit and push it and run a job on Jenkins because god forbid they support loading the library from anything besides source control, so you end up with a hundred commit messages like "gently caress it let's try putting this here." Abuse the replay functionality in Jenkins to test library changes so you don't make a million commits to test changes. Lucky for us, we haven't needed @NonCPS but in a few spots. Also peek at https://github.com/jenkinsci/JenkinsPipelineUnit for unit testing pipeline things. We have over 150 unit tests for our shared pipeline library and this made it possible.
|
|
#
?
Mar 9, 2018 17:31
|
|
|
Gitlab is cool
|
|
#
?
Mar 9, 2018 22:38
|
|
|
Gitlab is the first and only CI system I've used but I like it a lot. (I actually made things a bit more complicated for myself than I had to because I stubbornly decided I wanted to deploy Gitlab itself, the CI runner, and the glorified cronjob cleaning up old runner caches as a single docker-compose stack, and then I wanted to use the docker build executor on top of that. A plain old bare metal install is probably much easier to get up and running.) NihilCredo fucked around with this message at 22:53 on Mar 9, 2018 |
|
#
?
Mar 9, 2018 22:48
|
|
|
Git lab is pretty cool. They run all their builds on DigitalOcean too. Plug for my old company.
|
|
#
?
Mar 9, 2018 23:25
|
|
|
I already said my piece earlier in the thread for why Jenkins is an abomination that costs you in time and is therefore the worst option for smaller companies as a rule. Circle CI and Travis are all worth looking at for merely building software and deploying their artifacts - that’s that. Bitbucket pipelines and Gitlab CI may work for limited orchestration cases but Code Pipeline may be worth a try if you’re an AWS shop. Bitbucket pipelines is really barebones on features when I looked at it a couple weeeks ago but I know they’re trying to beef it up. If you are large and can afford the engineer time on Groovy DSL bullshit in Jenkins pipelines or can use Jenkins job builder, Jenkins may be viable. If you’re trying to build stuff without the horrors of Jenkins stateful configurations and node management, Concourse and Drone.io are your primary options. As a comedy option, maybe using Ansible Tower as CI with playbooks as builds could work.
|
|
#
?
Mar 9, 2018 23:31
|
|
|
Teamcity is real good. Every other CI server I've used I've been unimpressed with (Jenkins and Travis pretty much).
|
|
#
?
Mar 10, 2018 03:15
|
|
|
I'm a fan of concourse from using it at my last 2 workplaces. Once you get over the abstractions and realize it's just generic tasks running in a pipeline it becomes very flexible. Question for the more experienced devops people here. How do you normally interview for people devops positions? I might have to that soon, and I've only done dev interviews in the past.
|
|
#
?
Mar 11, 2018 05:22
|
|
|
|
| # ? May 16, 2024 09:13 |
|
|
Have the interviewer quantity their definition of DevOps to you at the outset. That’ll get you a decent idea of where they’re at as far as ops v admin v CI v lord knows what else.
|
|
#
?
Mar 11, 2018 07:08
|
|