Advice / Guidance
Hello dear redditors.
I've (27male) been working on a managerial position for an international company for 3 years. For last few month, I've been able to arrange my schedule in most confortable way, so I have plenty of free time on my hand. Mostly, I work for 2 days, 8hr shifts, and then I have 4 day offs, so I'm thinking to start a new journey, instead of gaming for whole day.
Since the childhood, I've been interested in computer science, however due to me living in underdeveloped country, it was practically impossible to study or to work on above mentioned sphere.
Fortunately, last few years and due to recent pandemic, there was an explosion of computer science, coding and development in my region. Two of my friends started high paying jobs in matter of months (backend and devops).
So, I've beend thinking if it's worth to start a journey and if so, what will be the most suitable field for 27yo, who has 0 knowledge regarding anything related to coding or programming.
Please share your experience, or give me some hint to start with.
Thank you.
https://redd.it/11iqxzp
@r_devops
Hello dear redditors.
I've (27male) been working on a managerial position for an international company for 3 years. For last few month, I've been able to arrange my schedule in most confortable way, so I have plenty of free time on my hand. Mostly, I work for 2 days, 8hr shifts, and then I have 4 day offs, so I'm thinking to start a new journey, instead of gaming for whole day.
Since the childhood, I've been interested in computer science, however due to me living in underdeveloped country, it was practically impossible to study or to work on above mentioned sphere.
Fortunately, last few years and due to recent pandemic, there was an explosion of computer science, coding and development in my region. Two of my friends started high paying jobs in matter of months (backend and devops).
So, I've beend thinking if it's worth to start a journey and if so, what will be the most suitable field for 27yo, who has 0 knowledge regarding anything related to coding or programming.
Please share your experience, or give me some hint to start with.
Thank you.
https://redd.it/11iqxzp
@r_devops
Reddit
r/devops on Reddit: Advice / Guidance
Posted by u/iliathomson1 - No votes and 6 comments
Should I use containers ( Docker / Podman ) for my app ?
I am running a node application and will host it online. Want to know if Docker ( or podman ) will be helpful for me for local and hosted environments.
If I don't use containers now how hard will it be to move to containers later on ?
Is there cost savings by running code in containers ?
Should the database run from a container or on the host itself ?
https://redd.it/11itblv
@r_devops
I am running a node application and will host it online. Want to know if Docker ( or podman ) will be helpful for me for local and hosted environments.
If I don't use containers now how hard will it be to move to containers later on ?
Is there cost savings by running code in containers ?
Should the database run from a container or on the host itself ?
https://redd.it/11itblv
@r_devops
Reddit
r/devops on Reddit: Should I use containers ( Docker / Podman ) for my app ?
Posted by u/purezen - No votes and 5 comments
CICD pipelines written in Typescript
Hi guys!
I've been using some tools client and server side to automate software deployment. To an extend where i needed more flexibility with pipeline definition!
I've been building a tool to execute pipelines written in Typescript (rust + deno under the hood)
I am working on the doc as we speak.
It's very different from what you may have been working with, but it solved my problems and still sticks to common pipeline paradigme!
Just wanted to share it with the outter world as I think It has become pretty mature over the past months.
What do u think of it? (work in progress)
Could it solve some of your issues!?
https://doc.pipelight.areskul.com/
https://redd.it/11ivfnu
@r_devops
Hi guys!
I've been using some tools client and server side to automate software deployment. To an extend where i needed more flexibility with pipeline definition!
I've been building a tool to execute pipelines written in Typescript (rust + deno under the hood)
I am working on the doc as we speak.
It's very different from what you may have been working with, but it solved my problems and still sticks to common pipeline paradigme!
Just wanted to share it with the outter world as I think It has become pretty mature over the past months.
What do u think of it? (work in progress)
Could it solve some of your issues!?
https://doc.pipelight.areskul.com/
https://redd.it/11ivfnu
@r_devops
Pipelight
A Lightweight CICD tool
What is the impact of not having Docker in your local development environment?
Former developer, turned architect here. I just joined a large transportation company which is just beginning their migration towards the cloud. We're onboarding a vendor to write some containerized applications for us to replace some legacy ones which we'll then host in GCP. We need to provide the vendor with development machines, however these machines will not have Docker, Podman, WSL2 etc due to large company reasons. My company's stance is that the developers can push their code through our CI/CD pipelines (ie; see if their Dockerfile is correct, if maven can create the containers, and push to a registry, integration tests work, etc etc).
My question is, does this sound like an anti-pattern to you? Personally, I feel that having to use the pipelines in this way would slow me down a few hours a week. I've already reached out to the vendor to see their opinion on it, but curious what you folks think about this scenario.
https://redd.it/11iwlej
@r_devops
Former developer, turned architect here. I just joined a large transportation company which is just beginning their migration towards the cloud. We're onboarding a vendor to write some containerized applications for us to replace some legacy ones which we'll then host in GCP. We need to provide the vendor with development machines, however these machines will not have Docker, Podman, WSL2 etc due to large company reasons. My company's stance is that the developers can push their code through our CI/CD pipelines (ie; see if their Dockerfile is correct, if maven can create the containers, and push to a registry, integration tests work, etc etc).
My question is, does this sound like an anti-pattern to you? Personally, I feel that having to use the pipelines in this way would slow me down a few hours a week. I've already reached out to the vendor to see their opinion on it, but curious what you folks think about this scenario.
https://redd.it/11iwlej
@r_devops
Reddit
r/devops on Reddit: What is the impact of not having Docker in your local development environment?
Posted by u/CoolZillionaire - No votes and 7 comments
Distribute private helm charts to customers for on prem install
What are peoples approach for distributing helm charts to customers that will be installing a product in their own kubernetes cluster? The two options I have considered
Sending each customer the tgz file which they can store in their own helm repository.
Host charts on dockerhub and add an account for each customer which they can use to pull the chart
Both approaches feel clunky but I haven't found any information on a different approach.
https://redd.it/11j3l0n
@r_devops
What are peoples approach for distributing helm charts to customers that will be installing a product in their own kubernetes cluster? The two options I have considered
Sending each customer the tgz file which they can store in their own helm repository.
Host charts on dockerhub and add an account for each customer which they can use to pull the chart
Both approaches feel clunky but I haven't found any information on a different approach.
https://redd.it/11j3l0n
@r_devops
Reddit
r/devops on Reddit: Distribute private helm charts to customers for on prem install
Posted by u/the_troll_toll89 - No votes and no comments
Networking for DevOps Roadmap
Does anyone have a roadmap for networking for DevOps? I'm afraid going too much in depth.
https://redd.it/11jbtbc
@r_devops
Does anyone have a roadmap for networking for DevOps? I'm afraid going too much in depth.
https://redd.it/11jbtbc
@r_devops
Reddit
r/devops on Reddit: Networking for DevOps Roadmap
Posted by u/izner82 - No votes and 2 comments
Crazy coworker manages entire development environment in single docker container
A friend of mine adds their entire development environment to a single docker container. This includes all the tooling like VS Code. Every couple months, he starts over fresh in a docker container.
I guess the logic is that he forces himself to only retain and use what's necessary, and cleans up unnecessary tooling.
Does this seem like a good practice? A bit over the top?
https://redd.it/11jd4ci
@r_devops
A friend of mine adds their entire development environment to a single docker container. This includes all the tooling like VS Code. Every couple months, he starts over fresh in a docker container.
I guess the logic is that he forces himself to only retain and use what's necessary, and cleans up unnecessary tooling.
Does this seem like a good practice? A bit over the top?
https://redd.it/11jd4ci
@r_devops
Reddit
r/devops on Reddit: Crazy coworker manages entire development environment in single docker container
Posted by u/_classname__spam - No votes and 9 comments
Building a devops "compiler"
Hey all, I'd like to discuss with this community a concept I've been working on and refining for a little over a year now, and would like to see if other people here would think this is a step in the right direction or misguided in some way.
I've worked in several different places as a software engineer and/or infrastructure engineer for years now, although in the last few I've found a real passion in building and optimizing automated infrastructure. I've found an incredible amount of satisfaction in spending months building out what is essentially a "factory" for delivering code and automating its various facets. Once it all comes together, you end up with this really nice, well-oiled machine that takes code as input and outputs running, certified, and observable applications.
What I've noticed doing this is that there isn't actually that much difference between what various software development teams want. I will narrow the domain down to the following types of applications:
- Listening for and responding to HTTP requests at some URL (e.g. websites, APIs)
- Performing some operation on a timed schedule (e.g. cronjobs)
- Listening for and reacting to some non-HTTP event (e.g. SFTP listener, Kafka/queue-based listener)
Notably, this does not include any sort of AI application, which I have never worked with and will not pretend to understand their devops requirements, or desktop applications. I'm sure there are others as well. The general gist is that I'm applying these ideas to software that is most comfortable sitting in a cloud-run VM and reacting to a push- or pull-based event. These types of applications can typically be run "statelessly" (as in they don't need hard drive storage attached to them, not that they don't use a DB or perhaps bucket-based storage mechanism), and can be scaled up or down/replicated easily.
For this domain of applications, a software development team will want the following:
- A CI loop that listens to their PRs, runs automated functionality, performance, and security tests, provides in-PR feedback as to the results of those tests, and certifies the PR based on the results of those tests and, optionally, the existence of a human review; additionally, on a merge to main, this loop will semantically version the changes based on a well-formatted commit message and tag the commit-level with that version, and generate artifacts for this new version (code coverage results, docker image(s) with appropriate tags, helm chart(s)/kubernetes resource package with appropriate tags)
- A CD loop that listens to newly generated artifact versions and automatically updates appropriate environments with the new version; this is typically automatic for a dev environment, but dependent on engineer approval for staging or prod environments
- A networking stack that automatically provides their application with a URL to communicate with once deployed, DNS for that URL, and TLS certs that are regularly rotated
- An observability stack that provides: a UI for quickly parsing through indexed application logs, a dashboard for visualizing metrics, a UI for searching through and using traces, and an alerting system that can utilize all three to generate notifications to the relevant on-call team
- A pre-built package they can quickly include in any codebase that will automatically instrument their code for the aforementioned observability stack, providing easy code hooks for shipping custom logs, metrics, and traces out of their code
- An identity provider connected to the networking stack that solves the authentication and UI login problem; preferably, authentication should be offloaded to the networking stack, such that a request reaching actual code can be assumed to be authenticated; the code can do further custom authorization checks once the request arrives, or this can also be offloaded to the networking stack
- A central secret and configuration management UI that automatically hooks into deployed code, provides the necessary config, and automatically rotates secrets
Hey all, I'd like to discuss with this community a concept I've been working on and refining for a little over a year now, and would like to see if other people here would think this is a step in the right direction or misguided in some way.
I've worked in several different places as a software engineer and/or infrastructure engineer for years now, although in the last few I've found a real passion in building and optimizing automated infrastructure. I've found an incredible amount of satisfaction in spending months building out what is essentially a "factory" for delivering code and automating its various facets. Once it all comes together, you end up with this really nice, well-oiled machine that takes code as input and outputs running, certified, and observable applications.
What I've noticed doing this is that there isn't actually that much difference between what various software development teams want. I will narrow the domain down to the following types of applications:
- Listening for and responding to HTTP requests at some URL (e.g. websites, APIs)
- Performing some operation on a timed schedule (e.g. cronjobs)
- Listening for and reacting to some non-HTTP event (e.g. SFTP listener, Kafka/queue-based listener)
Notably, this does not include any sort of AI application, which I have never worked with and will not pretend to understand their devops requirements, or desktop applications. I'm sure there are others as well. The general gist is that I'm applying these ideas to software that is most comfortable sitting in a cloud-run VM and reacting to a push- or pull-based event. These types of applications can typically be run "statelessly" (as in they don't need hard drive storage attached to them, not that they don't use a DB or perhaps bucket-based storage mechanism), and can be scaled up or down/replicated easily.
For this domain of applications, a software development team will want the following:
- A CI loop that listens to their PRs, runs automated functionality, performance, and security tests, provides in-PR feedback as to the results of those tests, and certifies the PR based on the results of those tests and, optionally, the existence of a human review; additionally, on a merge to main, this loop will semantically version the changes based on a well-formatted commit message and tag the commit-level with that version, and generate artifacts for this new version (code coverage results, docker image(s) with appropriate tags, helm chart(s)/kubernetes resource package with appropriate tags)
- A CD loop that listens to newly generated artifact versions and automatically updates appropriate environments with the new version; this is typically automatic for a dev environment, but dependent on engineer approval for staging or prod environments
- A networking stack that automatically provides their application with a URL to communicate with once deployed, DNS for that URL, and TLS certs that are regularly rotated
- An observability stack that provides: a UI for quickly parsing through indexed application logs, a dashboard for visualizing metrics, a UI for searching through and using traces, and an alerting system that can utilize all three to generate notifications to the relevant on-call team
- A pre-built package they can quickly include in any codebase that will automatically instrument their code for the aforementioned observability stack, providing easy code hooks for shipping custom logs, metrics, and traces out of their code
- An identity provider connected to the networking stack that solves the authentication and UI login problem; preferably, authentication should be offloaded to the networking stack, such that a request reaching actual code can be assumed to be authenticated; the code can do further custom authorization checks once the request arrives, or this can also be offloaded to the networking stack
- A central secret and configuration management UI that automatically hooks into deployed code, provides the necessary config, and automatically rotates secrets
regularly; this system should allow for the concept of shared and app-specific configuration, particularly for microservice-based architectures
- A pre-built configuration package they can easily include into any codebase that knows how to read the automatically provided config
- Infrastructure that will automatically scale their code up or down based on need, and scale itself up or down based on how much the code needs to be scaled
I'm generalizing and I'm sure there are some additional details I could add, but on the whole, the work I've seen devops teams pour time into has typically been to implement some subset of the above. I have seen teams have varying levels of success doing so with a whole bunch of different tools, some home-grown, some commercial, some open-source, but all of them quite different. And I'm sick of it.
We all want the same thing, and there is, GENERALLY SPEAKING, an "ideal" devops pipeline and infrastructure out there that checks all the boxes, but it requires strong interplay between assumptions made by the infrastructure and codebases fulfilling those assumptions. That brings me to my core thesis:
We need to start viewing devops and infrastructure like compilers, not editable pipelines
When you start writing code, you don't rewrite your compiler or your interpreter to fix your janky code. The compiler/interpreter knows what's right and what's wrong and publishes a clear interface for how you need to be doing things, and if you do them wrong, you fix your code, not the compiler/interpreter. Too many times have I seen teams force changes to a pipeline due to poor coding and software development practices rather than problems in a pipeline. Once those poor practices have been normalized it is incredibly difficult to change them. If you normalize good practices from day 1, everyone gets used to it and no one grumbles.
Our devops pipelines should provide a clear interface for what is considered acceptable code, and code should be modified to fit that interface, not the other way around
If the code fulfills the interface, infrastructure can make SO MANY assumptions that provides that same code a huge number of pre-configured systems and advantages that then don't need to be configured by a dedicated devops team.
A crucial part of accomplishing this successfully is providing a very easy-to-use entrypoint to that interface. Usually, I implement this in the form of "template" repos that act as quickstarts; this is a repo in the target coding language that has a main file with a clear entry point to start writing code and all the observability and config packages pre-configured. This repo will also typically include a compliant Dockerfile and Makefile. Make sure that as few build files have to be configured as possible. The idea here is to create a "pit of success": the easiest path is the correct path. A developer can clone the repo, start writing code, push the new repo, and the pipelines take care of the rest.
The trick is always to balance out maintaining enough customizability that most applications can fit the interface, without making it so generic that making things works requires a lot of app-specific work, but I believe there is a balance that fits MOST applications; not necessarily ALL applications, but MOST.
I've been building out such a system using exclusively open-source tools for the past year and I think it works quite well and is applicable to most of the companies I've worked at. What I like about it is there's no vendor lock-in and can be deployed single- or multi-tenant, so it could be deployed entirely separately or used as a PaaS. I'm having some trouble motivating myself to finish it recently and figured I'd get feedback from the devops community to hear if:
1. They apply these sorts of principles at their own jobs
2. If so, have they found it to be useful, and have they found success in doing so; if not, what technical or non-technical barriers have they encountered
3. If they know of any tools or companies that accomplish this or some subset of this (and
- A pre-built configuration package they can easily include into any codebase that knows how to read the automatically provided config
- Infrastructure that will automatically scale their code up or down based on need, and scale itself up or down based on how much the code needs to be scaled
I'm generalizing and I'm sure there are some additional details I could add, but on the whole, the work I've seen devops teams pour time into has typically been to implement some subset of the above. I have seen teams have varying levels of success doing so with a whole bunch of different tools, some home-grown, some commercial, some open-source, but all of them quite different. And I'm sick of it.
We all want the same thing, and there is, GENERALLY SPEAKING, an "ideal" devops pipeline and infrastructure out there that checks all the boxes, but it requires strong interplay between assumptions made by the infrastructure and codebases fulfilling those assumptions. That brings me to my core thesis:
We need to start viewing devops and infrastructure like compilers, not editable pipelines
When you start writing code, you don't rewrite your compiler or your interpreter to fix your janky code. The compiler/interpreter knows what's right and what's wrong and publishes a clear interface for how you need to be doing things, and if you do them wrong, you fix your code, not the compiler/interpreter. Too many times have I seen teams force changes to a pipeline due to poor coding and software development practices rather than problems in a pipeline. Once those poor practices have been normalized it is incredibly difficult to change them. If you normalize good practices from day 1, everyone gets used to it and no one grumbles.
Our devops pipelines should provide a clear interface for what is considered acceptable code, and code should be modified to fit that interface, not the other way around
If the code fulfills the interface, infrastructure can make SO MANY assumptions that provides that same code a huge number of pre-configured systems and advantages that then don't need to be configured by a dedicated devops team.
A crucial part of accomplishing this successfully is providing a very easy-to-use entrypoint to that interface. Usually, I implement this in the form of "template" repos that act as quickstarts; this is a repo in the target coding language that has a main file with a clear entry point to start writing code and all the observability and config packages pre-configured. This repo will also typically include a compliant Dockerfile and Makefile. Make sure that as few build files have to be configured as possible. The idea here is to create a "pit of success": the easiest path is the correct path. A developer can clone the repo, start writing code, push the new repo, and the pipelines take care of the rest.
The trick is always to balance out maintaining enough customizability that most applications can fit the interface, without making it so generic that making things works requires a lot of app-specific work, but I believe there is a balance that fits MOST applications; not necessarily ALL applications, but MOST.
I've been building out such a system using exclusively open-source tools for the past year and I think it works quite well and is applicable to most of the companies I've worked at. What I like about it is there's no vendor lock-in and can be deployed single- or multi-tenant, so it could be deployed entirely separately or used as a PaaS. I'm having some trouble motivating myself to finish it recently and figured I'd get feedback from the devops community to hear if:
1. They apply these sorts of principles at their own jobs
2. If so, have they found it to be useful, and have they found success in doing so; if not, what technical or non-technical barriers have they encountered
3. If they know of any tools or companies that accomplish this or some subset of this (and
I don't mean things like DataDog or CircleCI, which in my mind fulfill a very small, specific subset of these)
If you made it this far thank you very much for reading!
https://redd.it/11jflm2
@r_devops
If you made it this far thank you very much for reading!
https://redd.it/11jflm2
@r_devops
Reddit
r/devops on Reddit: Building a devops "compiler"
Posted by u/ajpauwels - No votes and 4 comments
Is anyone using SPACE instead of DORA?
I was wondering if anyone is using SPACE to measure the performance of developer teams? Maybe instead of the DORA KPIs? Here are two links to SPACE in case you never heard about it before:
SPACE, a New Framework to Understand and Measure Developer Productivity (infoq.com)
The SPACE of Developer Productivity - ACM Queue
Any experience? Thoughts? Relevant links?
https://redd.it/11jgouz
@r_devops
I was wondering if anyone is using SPACE to measure the performance of developer teams? Maybe instead of the DORA KPIs? Here are two links to SPACE in case you never heard about it before:
SPACE, a New Framework to Understand and Measure Developer Productivity (infoq.com)
The SPACE of Developer Productivity - ACM Queue
Any experience? Thoughts? Relevant links?
https://redd.it/11jgouz
@r_devops
InfoQ
SPACE, a New Framework to Understand and Measure Developer Productivity
A recent paper by researchers at GitHub, University of Victoria, and Microsoft delves into developer productivity to propose a new approach to defining, measuring and predicting it. InfoQ has taken the chance to speak with the paper lead author, GitHub vice…
WFH devs, what does your company provide you to work on?
Just curious what other devs are using for WFH.
View Poll
https://redd.it/11jgd0c
@r_devops
Just curious what other devs are using for WFH.
View Poll
https://redd.it/11jgd0c
@r_devops
Reddit
r/devops on Reddit: WFH devs, what does your company provide you to work on?
Posted by u/fez0101 - No votes and 15 comments
Damn I just passed Cisco Certified DevNet Specialist - DevOps specialisation!!!
OMG I am over the moon!!!!
I can’t even write still shaking lol!!!
Cisco DevNet Professional I managed to bypass the associate level!!!
A lot of overlapping concepts with this and GCP Professional DevOps
I will write on this later…
https://redd.it/11jln8y
@r_devops
OMG I am over the moon!!!!
I can’t even write still shaking lol!!!
Cisco DevNet Professional I managed to bypass the associate level!!!
A lot of overlapping concepts with this and GCP Professional DevOps
I will write on this later…
https://redd.it/11jln8y
@r_devops
Reddit
r/devops on Reddit: Damn I just passed Cisco Certified DevNet Specialist - DevOps specialisation!!!
Posted by u/TahaTheNetAutmator - No votes and no comments
Licensing temporary Windows Servers on KVM Hosts
So I’m trying to figure out how to license Windows Server for temporary dev & test servers. How do you guys do it? Do you just use the trial period or do you use some form of license?
The problem I see with the trial period is customising the image while still not starting the counter and using the current date.
Any tips and thoughts are appreciated!
https://redd.it/11jle3r
@r_devops
So I’m trying to figure out how to license Windows Server for temporary dev & test servers. How do you guys do it? Do you just use the trial period or do you use some form of license?
The problem I see with the trial period is customising the image while still not starting the counter and using the current date.
Any tips and thoughts are appreciated!
https://redd.it/11jle3r
@r_devops
Reddit
r/devops on Reddit: Licensing temporary Windows Servers on KVM Hosts
Posted by u/elasticweed - No votes and 7 comments
From Startup to Success: Why Adopting a DevOps Approach Is Essential
Learn why a DevOps approach is crucial for startup businesses to achieve success. From improving collaboration to accelerating time to market, discover how DevOps practices can help your business thrive in the competitive landscape. Don't fall behind - make DevOps a priority for your startup today. Scoop of Everything about Devops for Your Business Growth.
https://redd.it/11jqtv6
@r_devops
Learn why a DevOps approach is crucial for startup businesses to achieve success. From improving collaboration to accelerating time to market, discover how DevOps practices can help your business thrive in the competitive landscape. Don't fall behind - make DevOps a priority for your startup today. Scoop of Everything about Devops for Your Business Growth.
https://redd.it/11jqtv6
@r_devops
MultiQoS
Why Adopting a DevOps Approach is Important for Your Business
Find out why DevOps is critical for startups and how it can drive success. Learn the 6 reasons now and take action to improve your startup's efficiency, collaboration, & innovation.
Getting CISCO Networking Certifications
How useful are Cisco certifications in terms of the knowledge they could provide for DevOps (If I already know the basics of Networking)? Is that worth going deeper in knowledge about networking with certifications from CISCO
https://redd.it/11k1wgg
@r_devops
How useful are Cisco certifications in terms of the knowledge they could provide for DevOps (If I already know the basics of Networking)? Is that worth going deeper in knowledge about networking with certifications from CISCO
https://redd.it/11k1wgg
@r_devops
Reddit
r/devops on Reddit: Getting CISCO Networking Certifications
Posted by u/RP_m_13 - No votes and 1 comment
Weird git branch rule
I am working on a place that has a weird branch rule.They said that 2 branches could not be merged into the main, under no circumstances.These branches are used to test stuff.If you want to test something, you should merge your branch in the test branch or another specific branch for it. Since you cannot merge these branches back to the main, what is the point?They use gitlab flow (at least that is what they claim)
It seems like these break everything I know about CI. Does anyone worked in something similar?
Edit: I forgot to mention, we are no allowed to create branch from theses 2 branchs. Theses branch's only run unit tests.
https://redd.it/11k1d65
@r_devops
I am working on a place that has a weird branch rule.They said that 2 branches could not be merged into the main, under no circumstances.These branches are used to test stuff.If you want to test something, you should merge your branch in the test branch or another specific branch for it. Since you cannot merge these branches back to the main, what is the point?They use gitlab flow (at least that is what they claim)
It seems like these break everything I know about CI. Does anyone worked in something similar?
Edit: I forgot to mention, we are no allowed to create branch from theses 2 branchs. Theses branch's only run unit tests.
https://redd.it/11k1d65
@r_devops
Reddit
r/devops on Reddit: Weird git branch rule
Posted by u/No_Butterfly_1888 - No votes and 9 comments
How do you create your Kubernetes configuration?
I was wondering how do you create your Kubernetes resources so that everything is stable and secure.
There are many ways of improving the quality of the artefacts created, but I wonder if you are actually dedicating some effort to generate the best configuration manifests possible, or getting it out of the way.
View Poll
https://redd.it/11k5m75
@r_devops
I was wondering how do you create your Kubernetes resources so that everything is stable and secure.
There are many ways of improving the quality of the artefacts created, but I wonder if you are actually dedicating some effort to generate the best configuration manifests possible, or getting it out of the way.
View Poll
https://redd.it/11k5m75
@r_devops
Reddit
r/devops on Reddit: How do you create your Kubernetes configuration?
Posted by u/chargi0 - No votes and no comments
Legality of employer not paying for oncall?
My employer capped the oncall hours they pay out. In theory it's "to give us more wlb." Post layoffs we're all now going over the limit because there are fewer people oncall. So we're working for free. Is this legal? This is in California.
https://redd.it/11k4a5r
@r_devops
My employer capped the oncall hours they pay out. In theory it's "to give us more wlb." Post layoffs we're all now going over the limit because there are fewer people oncall. So we're working for free. Is this legal? This is in California.
https://redd.it/11k4a5r
@r_devops
Reddit
r/devops on Reddit: Legality of employer not paying for oncall?
Posted by u/IdesOfMarchCometh - No votes and 11 comments
Should CI/CD tooling build & deploy its own configuration and infrastructure?
An ongoing conversation I'm having with a colleague regarding our Jenkins infrastructure. Our Jenkins' deployment is specified by several layers of infrastructure/configuration-as-code: terraform, Ansible, CasC, shared libraries, packer images for build agents. Each of these is specified in git, and changes require testing, validation, packaging, and release automation.
Some such changes are currently built/tested/deployed manually. Some are managed by an external system. Some are managed by Jenkins itself. We are in a long conversation about what's the most "correct" system on which to manage these processes.
Doing things manually: pros, simple to reason about; cons, risks around human error, repeatability, velocity
External system: pros, segregation of duties, no "recursive" loops; cons, getting into a turtles-all-the-way-down situation
Self-management: pros, fewer cicd platforms to maintain, pipeline code written using same syntax and elements as other pipelines; cons, if a bad release breaks CICD you might lock yourself out, any vulnerabilities in the CICD platform might be magnified if it has permission to alter itself.
This question might be more relevant for self-hosted solutions than SaaS tools. However, to those who would suggest we move away from Jenkins: (a) easier said than done, there's a decade of technical inertia behind our installation that would need to be migrated to a another tool (b) it's stable, performant, and well understood, there's no urgent business need to migrate (c) the theoretical problem would certainly exist with any other self hosted tool, and would have arguable parallels in a SaaS solution.
This isn't an urgent problem, things work mostly pretty well. I'm more interested in what an idealized architecture would look like, and how other people are approaching this topic.
https://redd.it/11k6nip
@r_devops
An ongoing conversation I'm having with a colleague regarding our Jenkins infrastructure. Our Jenkins' deployment is specified by several layers of infrastructure/configuration-as-code: terraform, Ansible, CasC, shared libraries, packer images for build agents. Each of these is specified in git, and changes require testing, validation, packaging, and release automation.
Some such changes are currently built/tested/deployed manually. Some are managed by an external system. Some are managed by Jenkins itself. We are in a long conversation about what's the most "correct" system on which to manage these processes.
Doing things manually: pros, simple to reason about; cons, risks around human error, repeatability, velocity
External system: pros, segregation of duties, no "recursive" loops; cons, getting into a turtles-all-the-way-down situation
Self-management: pros, fewer cicd platforms to maintain, pipeline code written using same syntax and elements as other pipelines; cons, if a bad release breaks CICD you might lock yourself out, any vulnerabilities in the CICD platform might be magnified if it has permission to alter itself.
This question might be more relevant for self-hosted solutions than SaaS tools. However, to those who would suggest we move away from Jenkins: (a) easier said than done, there's a decade of technical inertia behind our installation that would need to be migrated to a another tool (b) it's stable, performant, and well understood, there's no urgent business need to migrate (c) the theoretical problem would certainly exist with any other self hosted tool, and would have arguable parallels in a SaaS solution.
This isn't an urgent problem, things work mostly pretty well. I'm more interested in what an idealized architecture would look like, and how other people are approaching this topic.
https://redd.it/11k6nip
@r_devops
Reddit
r/devops on Reddit: Should CI/CD tooling build & deploy its own configuration and infrastructure?
Posted by u/Ok-Photo-7835 - No votes and 2 comments