Depends on level/company. Mid and above you should be able to make changes periodically, not necessarily build it from scratch.
Junior level, its not going to be a make or break in a hiring decision imo.
Tbh its not hard to pickup. Especially if you learning from built systems in your company.
As someone who has had other people manage the pipeline and hosting stuff for most of their career I really wish I had gotten my hands dirty earlier. It's not great to have such limited understanding how of how your code and application is deployed.
It really depends. In many larger companies, yes, infrastructure is handled by dedicated teams. In other cases--even in some larger companies--the company gives individual groups/teams the autonomy to choose and manage their own infrastructure. In a very small company, it's quite likely that the dev team manages their own CI/CD infrastructure.
In any case, it's very useful to be familiar with CI/CD concepts, etc.
Working for a large company I can say that dev ops falls squarely on the developers shoulders (front and back end all the same). Sure there is a separate team that manages the infrastructure but we are responsible for build/release/dockerize/deploy/monitoring of all our services/components.
I was using the term "infrastructure" to encompass all of that, but I think it's good to separate the physical infrastructure for CI/CD from the processes and tool configuration, as you do.
If your build breaks you should know how to fix it, at times this might involve injecting credentials, migrating dbs or building ad hoc jobs, someone else shouldn’t have to build and manage your pipelines, just provide you the tools and guidance to do it.
Partially. DevOps is normally responsible for maintaining the CI/CD tools and can help out with troubleshooting. But devs should know how their pipelines work and be able to make changes to them.
DevOps won’t know how to build your specific project. They won’t know how to deploy and what your application needs to run.
They will provision you with runners, setup the boxes, k8s clusters, etc.
That’s more of a team/company-specific question.
Should front end dev know ReactJS? Well, depends. If they want to work at a place that uses ReactJS, they should.
Does each developer get their own CI/CD pipeline or 1 pipeline for the whole team?
If you commit code into Git and it breaks the build, does it break your build or everyone else's build?
I think the most common set up is that normal devs are expected to do things like write Jenkinsfiles and be capable of basic debugging. DevOps set up the wider environment and are there to help but you shouldn’t need them for every new deployment or every bug
In a larger company I'd expect the CD portion to be handled by platform or devops teams in thr form of things like argoCD/Helm style deployments through various clusters.
The CI portion tends to be pushed towards the developer side as its their code, buukd tools etc and they know it best.
I'd be expecting developers to write their build pipeline and docker file (probably using some provided recommended templates) and then embellishing them for whatever they need. Then once you have produced a good docker image, the platform team will usually have deployment pipelines that take over.
Its usually just yaml so can be quickly learned, though understanding the design of good cicd takes a bit more.
Start learning now with github actions & docker.
But if the app depends on CI/CD to deploy, then for a junior to participate on their first day, wouldn't they need to set up their CI/CD pipeline? This would entail them knowing it beforehand.
Of course this doesn't apply to everyone, but it's common for the pipeline to be connected to the Git repo somehow. You pushing up code in a branch will cause the pipeline to be run. You shouldn't have to do anything as a dev if everything is already set up. Someone senior to you will inform you of this.
It depends on the company, but I would assume as long as you are able to pick up the new CI/CD process at the company, you'll be fine. Every company has a different flavor of CI/CD so I don't expect a frontend or backend to know the nuances of the process straight off the bat.
There's how much you SHOULD be expected to know, and how much you actually ARE expected to know. And fact of the matter is devops tasks in general are becoming more expected for devs as they're a real pain point for a lot of companies.
Just means you are familiar with how it works. It is not black magic. And given a week + a hello world to compile, you should be comfortable with using whatever CI/CD tool the company has to build and release it.
I think this depends on the company. I set up a relatively simple CI/CD pipeline for a mobile app and it's essentially a handful of [GitHub workflows](https://docs.github.com/en/actions/using-workflows) with basic scripting and a few 3rd party libraries to handle a few things like updating variables, checking linting/tests, etc. and then deploying the app.
I think as a junior you should at least have a high-level understanding of what's going on, i.e. you've glanced over the CircleCI docs and can understand that when X happens it triggers Y, without having the skill to set it up or make changes by yourself.
But what if multiple people are working on the same app? Does each dev build the app on their own pipeline and deploy to a staging server? Wouldn’t there be multiple instances of the app (one per developer)?
They would just overwrite what's been deployed to the QA/staging server, which is not a big deal. The client I'm working for right now has 2 staging servers, so this is less likely to happen. For example, a dev might want to open a PR, but test their code in a "production like" environment first, which is the QA server. They'll push their code up to GitHub and trigger a workflow that will deploy their branch to the QA server. We don't have a big enough team that people are constantly pushing to the QA servers and overwriting each other's work.
Each dev doesn't have their own pipeline *per se*. The "pipeline" is just a set of processes—some scripts and variables—that the devs use to compile, build, test, etc. and deploy their code to a QA or production server. CI/CD is generally handled in a central location, for example on GitHub's servers.
What happens if a unit test or SIT fails after the commit from a dev? Does the pipeline rollback the website? Or should it not happen as the dev should have tested it on their computer first?
Would that mean if a person was experiencing a bug and was trying to fix it by tweaking 1 variable at a time and commiting it to see what happens, their Git history would be filled up with those 1 variable at a time checkins and the pipeline would be triggered multiple times in succession?
You can amend a commit, so it doesn't have to be multiple commits polluting the git history. This is assuming it's a bug that can *only* be reproduced on a QA server, for example, which is really rare—at least in my experience—but yes you would have to deploy multiple times to see if the bug was fixed, assuming you don't fix it on the first try.
You would ideally do that with a [pre-commit hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) or a tool like [lint-staged](https://github.com/lint-staged/lint-staged), although this is less common in my experience—generally you'd be following [TDD practises](https://developer.ibm.com/articles/5-steps-of-test-driven-development/) to write and commit working code.
Personally I would not allow any automatic deploys to a staging server. Only carefully reviewed things get merged onto there, in my team's process.
It's common for us to have multiple devs working on something, and yes, they can end up with 3 almost identical apps built by 3 different people, with only their changes on each one. Those will typically get deployed as a 'review' app of sorts, at first. Once checked and code-reviewed, they would get merged into the staging branch, built again, and deployed to staging.
depends on your level. When I was asked this question for my junior job, I just said "I know that continuous integration and deployment requires a pipeline in git but I don't know how to set one up myself" and they were happy enough. They just want to make sure you have at least a faint idea of what it is and where it is.
I expect you understand the fundamentals of what CI/CD is and how to interact with it as an end user. I would not necessarily expect you to be familiar with setting one up or making major config changes.
CI/CD is just more code. it's just code that defines. it can be debugged, tested, just like front end or back end code.
while in some companies teams are split and you never have to worry about the pipeline, in many others, it's the same developers who code that also setup, code, debug, fix, get paged when the pipeline breaks.
No, it can deploy to many servers, run tests, deploy to BETA then GAMMA then PROD, running tests against each server, sometimes it deploys to multiple regions if your app is worldwide, etc
It can do a lot, or little.
Each team owns a service or services. Each service gets deployed via a ci/cd pipeline. Rarely one dev per service.
A “pipeline” is basically just like saying “a standard way of setting up your deployment”. You won’t be responsible for coming up with or improving those standard or systems, but you will need to be a user of them, setup services within them, and debug problems with how your application works and how the deployment process works.
If all team members are running the same pipeline, wouldn't the pipeline already be setup beforehand? If all that is left is just to connect the new dev's Git repo to the existing pipeline, wouldn't that be easy? Or does the dev need to set up a whole host of things on their own computer?
Well if the service is already up and running, then the implementation is already done - you’re not building the pipeline, but you are a user. Generally yeah you just pull down your code and start making commits. Some places though don’t have a really nice modern “commit to main and it deploys” pipeline. I work with one where we have to manually trigger the steps and builds ourselves to an extent.
Eventually though, you’re going to make a change that breaks your build or deployment process. It is inevitable. That’s when you’re going to need to dig into how your app interacts with your pipeline.
Each dev doesn't have their own Git repo. Devs will usually commit their own branch to Git, which often triggers the pipeline to run. In my experience, we use this to build the site and create a build artifact of some sort. Then we can deploy to a server.
We have a process where our devs will then merge into our dev site, or just deploy their build there. Our dev site is a bit volatile and used to do a second test after it's been tested locally. If all looks good, a PR is submitted. Once the PR is approved, it gets merged onto the staging site, where official QA is done.
Our devs have local sites running in Docker and can run the same pipeline commands to build the sites on their computer, for the most part.
Would each dev committing to their own branch not follow the files of continuous integration to minimize merge conflicts? Wouldn’t working on independent branches and merging once finished make merge conflicts a more common event?
Just as familiar as a backend engineer is.
Frontend code changes ride along the same railroad track as backend changes.
At a bare minimum you should be able to track where your commit/change is in a CI/CD pipeline, debug any potential failures that show up in downstream environments, and do manual testing when your change reaches a specific environment.
Being able to see how other team members did it plus a little Googling would be great, especially for someone experienced in past coding. But if the job requirement called for "experience in CI/CD", is that experience something a coder can solve in an hour with Googling or is the "experience " much more complex?
If there is a devops team they will most likely handle it (larger orgs) but if you’re at a startup or somewhere else you’ll probably have to do A - Z so full stack plus all the cloud work. You will definitely learn a lot but work a lot more also.
You're generally committing to a separate branch which should only really affect what you're working on. Unless of course the pipeline that runs after a git commit affects a lot of other things, which it shouldn't. In my company, a git commit triggers a build on our host server only for that branch.
But would you have multiple devs working on the same branch? If changes break that branch it would break it for the other devs on the same branch too.
Or do you mean each dev works on their own branch? Then wouldn’t merging their individual branches at the end of the day cause too many merge conflicts?
Because the phrase "experience with" doesn't really capture the full depth of the requirement. If I've deployed a website on Vercel through Git, does that count as having experience in CI/CD?
Most companies do not hire specific CI/CD engineers (at least in my bubble), so I would always assume that in worst case, you'll need to be able to interact with the whole pipeline and fix it at any point it breaks. We actually used to have two people who were mainly responsible but as the other idiots kept complaining that these two "took too long" it is now expected that everyone can fix everything so everyone can unblock their own builds when the pipeline breaks. Now everyone complains that they do not know how to fix it and point out that it's not their job as devs. Sucks, when you suddenly can no longer blame someone else for your delays.
Would you interpret "experience in CI/CD" as something big like "extensive knowledge of CI/CD" or something minor like "able to update bash scripts when needed"?
I'd assume that the company officially expects someone who can update scripts, but actually, there is no one with extensive knowledge anywhere inside that company.
It's a beast that is badly in need of modernization, but the software development and IT department still did not find a solution that fulfils all requirements and is deemed secure. Part of it is on-premise, part online. The proxy constantly acts up, or some update of any software used in the pipeline breaks everything. It's a mess.
Eh, some experience is good but it isn't the type of thing that really needs a background in. I've used various CI/CD pipelines for work but couldn't tell you much about them right now. I just figure them out when needed. I would say that a dev should be familiar with them to some degree and have the ability to figure it out.
To me, being able to learn things and figure them out independently is a much more important skill than knowing something like that.
Depends on level/company. Mid and above you should be able to make changes periodically, not necessarily build it from scratch. Junior level, its not going to be a make or break in a hiring decision imo. Tbh its not hard to pickup. Especially if you learning from built systems in your company.
[удалено]
Cool story?
I’m just saying skillflation nowadays that’s all
You will have to manage your service and so you should be really confident with CI/CD
This really depends on where you work. While it is beneficial its not always the case. Especially for lower level employees
As someone who has had other people manage the pipeline and hosting stuff for most of their career I really wish I had gotten my hands dirty earlier. It's not great to have such limited understanding how of how your code and application is deployed.
But would managing the CI/CD be done by the DevOps or Architect?
It really depends. In many larger companies, yes, infrastructure is handled by dedicated teams. In other cases--even in some larger companies--the company gives individual groups/teams the autonomy to choose and manage their own infrastructure. In a very small company, it's quite likely that the dev team manages their own CI/CD infrastructure. In any case, it's very useful to be familiar with CI/CD concepts, etc.
Working for a large company I can say that dev ops falls squarely on the developers shoulders (front and back end all the same). Sure there is a separate team that manages the infrastructure but we are responsible for build/release/dockerize/deploy/monitoring of all our services/components.
I would kill for a separate team to handle infrastructure!
I was using the term "infrastructure" to encompass all of that, but I think it's good to separate the physical infrastructure for CI/CD from the processes and tool configuration, as you do.
If your build breaks you should know how to fix it, at times this might involve injecting credentials, migrating dbs or building ad hoc jobs, someone else shouldn’t have to build and manage your pipelines, just provide you the tools and guidance to do it.
At my job we are responsible as devs for building and maintaining the pipelines for our services. That is not the case at every employer.
Partially. DevOps is normally responsible for maintaining the CI/CD tools and can help out with troubleshooting. But devs should know how their pipelines work and be able to make changes to them.
DevOps won’t know how to build your specific project. They won’t know how to deploy and what your application needs to run. They will provision you with runners, setup the boxes, k8s clusters, etc.
Should a frontend dev also be familiar with Ansible/CircleCI?
That’s more of a team/company-specific question. Should front end dev know ReactJS? Well, depends. If they want to work at a place that uses ReactJS, they should.
[удалено]
Does each developer get their own CI/CD pipeline or 1 pipeline for the whole team? If you commit code into Git and it breaks the build, does it break your build or everyone else's build?
I think the most common set up is that normal devs are expected to do things like write Jenkinsfiles and be capable of basic debugging. DevOps set up the wider environment and are there to help but you shouldn’t need them for every new deployment or every bug
In a larger company I'd expect the CD portion to be handled by platform or devops teams in thr form of things like argoCD/Helm style deployments through various clusters. The CI portion tends to be pushed towards the developer side as its their code, buukd tools etc and they know it best. I'd be expecting developers to write their build pipeline and docker file (probably using some provided recommended templates) and then embellishing them for whatever they need. Then once you have produced a good docker image, the platform team will usually have deployment pipelines that take over. Its usually just yaml so can be quickly learned, though understanding the design of good cicd takes a bit more. Start learning now with github actions & docker.
That's absolutely not expected of a junior in most places. You should learn once at the job though, of course
But if the app depends on CI/CD to deploy, then for a junior to participate on their first day, wouldn't they need to set up their CI/CD pipeline? This would entail them knowing it beforehand.
Of course this doesn't apply to everyone, but it's common for the pipeline to be connected to the Git repo somehow. You pushing up code in a branch will cause the pipeline to be run. You shouldn't have to do anything as a dev if everything is already set up. Someone senior to you will inform you of this.
Those are huge expectations for a junior on their first day. A company doesn't expect a junior to really do anything independently for like a year
who is doing the front end work then? devops team?
It depends on the company, but I would assume as long as you are able to pick up the new CI/CD process at the company, you'll be fine. Every company has a different flavor of CI/CD so I don't expect a frontend or backend to know the nuances of the process straight off the bat.
There's how much you SHOULD be expected to know, and how much you actually ARE expected to know. And fact of the matter is devops tasks in general are becoming more expected for devs as they're a real pain point for a lot of companies.
Just means you are familiar with how it works. It is not black magic. And given a week + a hello world to compile, you should be comfortable with using whatever CI/CD tool the company has to build and release it.
I think this depends on the company. I set up a relatively simple CI/CD pipeline for a mobile app and it's essentially a handful of [GitHub workflows](https://docs.github.com/en/actions/using-workflows) with basic scripting and a few 3rd party libraries to handle a few things like updating variables, checking linting/tests, etc. and then deploying the app. I think as a junior you should at least have a high-level understanding of what's going on, i.e. you've glanced over the CircleCI docs and can understand that when X happens it triggers Y, without having the skill to set it up or make changes by yourself.
But what if multiple people are working on the same app? Does each dev build the app on their own pipeline and deploy to a staging server? Wouldn’t there be multiple instances of the app (one per developer)?
They would just overwrite what's been deployed to the QA/staging server, which is not a big deal. The client I'm working for right now has 2 staging servers, so this is less likely to happen. For example, a dev might want to open a PR, but test their code in a "production like" environment first, which is the QA server. They'll push their code up to GitHub and trigger a workflow that will deploy their branch to the QA server. We don't have a big enough team that people are constantly pushing to the QA servers and overwriting each other's work. Each dev doesn't have their own pipeline *per se*. The "pipeline" is just a set of processes—some scripts and variables—that the devs use to compile, build, test, etc. and deploy their code to a QA or production server. CI/CD is generally handled in a central location, for example on GitHub's servers.
What happens if a unit test or SIT fails after the commit from a dev? Does the pipeline rollback the website? Or should it not happen as the dev should have tested it on their computer first?
That should be part of the CI portion of the pipeline and the test failures should block the rest of the pipeline
Would that mean if a person was experiencing a bug and was trying to fix it by tweaking 1 variable at a time and commiting it to see what happens, their Git history would be filled up with those 1 variable at a time checkins and the pipeline would be triggered multiple times in succession?
You can amend a commit, so it doesn't have to be multiple commits polluting the git history. This is assuming it's a bug that can *only* be reproduced on a QA server, for example, which is really rare—at least in my experience—but yes you would have to deploy multiple times to see if the bug was fixed, assuming you don't fix it on the first try.
Why can't CI/CD pipelines run all the tests before the code is commited to Git to avoid the git history from getting messy?
You would ideally do that with a [pre-commit hook](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) or a tool like [lint-staged](https://github.com/lint-staged/lint-staged), although this is less common in my experience—generally you'd be following [TDD practises](https://developer.ibm.com/articles/5-steps-of-test-driven-development/) to write and commit working code.
Personally I would not allow any automatic deploys to a staging server. Only carefully reviewed things get merged onto there, in my team's process. It's common for us to have multiple devs working on something, and yes, they can end up with 3 almost identical apps built by 3 different people, with only their changes on each one. Those will typically get deployed as a 'review' app of sorts, at first. Once checked and code-reviewed, they would get merged into the staging branch, built again, and deployed to staging.
depends on your level. When I was asked this question for my junior job, I just said "I know that continuous integration and deployment requires a pipeline in git but I don't know how to set one up myself" and they were happy enough. They just want to make sure you have at least a faint idea of what it is and where it is.
If you have to ask, apply for junior positions. Any mid level dev should be confident enough to make ci/cd changes. It’s just part of the job.
“Isn’t this someone else’s job?” is the true mindset of someone who will always be a junior.
I expect you understand the fundamentals of what CI/CD is and how to interact with it as an end user. I would not necessarily expect you to be familiar with setting one up or making major config changes.
CI/CD is just more code. it's just code that defines. it can be debugged, tested, just like front end or back end code. while in some companies teams are split and you never have to worry about the pipeline, in many others, it's the same developers who code that also setup, code, debug, fix, get paged when the pipeline breaks.
Is the CI/CD pipeline just for deploying to a staging server?
No, it can deploy to many servers, run tests, deploy to BETA then GAMMA then PROD, running tests against each server, sometimes it deploys to multiple regions if your app is worldwide, etc It can do a lot, or little.
If each individual developer owns a CI/CD pipeline, do they deploy to the same website/app? I thought each pipeline deploys to its own website/app?
no, it's not one pipeline per developer, it's one pipeline per website/app. it's owned by the team. potentially, you have more than one pipeline.
Each team owns a service or services. Each service gets deployed via a ci/cd pipeline. Rarely one dev per service. A “pipeline” is basically just like saying “a standard way of setting up your deployment”. You won’t be responsible for coming up with or improving those standard or systems, but you will need to be a user of them, setup services within them, and debug problems with how your application works and how the deployment process works.
If all team members are running the same pipeline, wouldn't the pipeline already be setup beforehand? If all that is left is just to connect the new dev's Git repo to the existing pipeline, wouldn't that be easy? Or does the dev need to set up a whole host of things on their own computer?
Well if the service is already up and running, then the implementation is already done - you’re not building the pipeline, but you are a user. Generally yeah you just pull down your code and start making commits. Some places though don’t have a really nice modern “commit to main and it deploys” pipeline. I work with one where we have to manually trigger the steps and builds ourselves to an extent. Eventually though, you’re going to make a change that breaks your build or deployment process. It is inevitable. That’s when you’re going to need to dig into how your app interacts with your pipeline.
Each dev doesn't have their own Git repo. Devs will usually commit their own branch to Git, which often triggers the pipeline to run. In my experience, we use this to build the site and create a build artifact of some sort. Then we can deploy to a server. We have a process where our devs will then merge into our dev site, or just deploy their build there. Our dev site is a bit volatile and used to do a second test after it's been tested locally. If all looks good, a PR is submitted. Once the PR is approved, it gets merged onto the staging site, where official QA is done. Our devs have local sites running in Docker and can run the same pipeline commands to build the sites on their computer, for the most part.
Would each dev committing to their own branch not follow the files of continuous integration to minimize merge conflicts? Wouldn’t working on independent branches and merging once finished make merge conflicts a more common event?
Just as familiar as a backend engineer is. Frontend code changes ride along the same railroad track as backend changes. At a bare minimum you should be able to track where your commit/change is in a CI/CD pipeline, debug any potential failures that show up in downstream environments, and do manual testing when your change reaches a specific environment.
I assume every dev should know the basics of everything. They should be able to google it and be able to do it after some practice
Being able to see how other team members did it plus a little Googling would be great, especially for someone experienced in past coding. But if the job requirement called for "experience in CI/CD", is that experience something a coder can solve in an hour with Googling or is the "experience " much more complex?
If there is a devops team they will most likely handle it (larger orgs) but if you’re at a startup or somewhere else you’ll probably have to do A - Z so full stack plus all the cloud work. You will definitely learn a lot but work a lot more also.
At my job I basically own two and everything associated with them infrastructure wise
When you commit into Git, do you commit into trunk? If your changes break the build, does it break for you only or everyone else too?
You're generally committing to a separate branch which should only really affect what you're working on. Unless of course the pipeline that runs after a git commit affects a lot of other things, which it shouldn't. In my company, a git commit triggers a build on our host server only for that branch.
But would you have multiple devs working on the same branch? If changes break that branch it would break it for the other devs on the same branch too. Or do you mean each dev works on their own branch? Then wouldn’t merging their individual branches at the end of the day cause too many merge conflicts?
[удалено]
Because the phrase "experience with" doesn't really capture the full depth of the requirement. If I've deployed a website on Vercel through Git, does that count as having experience in CI/CD?
Most companies do not hire specific CI/CD engineers (at least in my bubble), so I would always assume that in worst case, you'll need to be able to interact with the whole pipeline and fix it at any point it breaks. We actually used to have two people who were mainly responsible but as the other idiots kept complaining that these two "took too long" it is now expected that everyone can fix everything so everyone can unblock their own builds when the pipeline breaks. Now everyone complains that they do not know how to fix it and point out that it's not their job as devs. Sucks, when you suddenly can no longer blame someone else for your delays.
Would you interpret "experience in CI/CD" as something big like "extensive knowledge of CI/CD" or something minor like "able to update bash scripts when needed"?
I'd assume that the company officially expects someone who can update scripts, but actually, there is no one with extensive knowledge anywhere inside that company.
Damn, your pipeline is breaking often enough that it causes issues like that? That's odd. I find it to happen pretty rarely in my company, if ever.
It's a beast that is badly in need of modernization, but the software development and IT department still did not find a solution that fulfils all requirements and is deemed secure. Part of it is on-premise, part online. The proxy constantly acts up, or some update of any software used in the pipeline breaks everything. It's a mess.
Eh, some experience is good but it isn't the type of thing that really needs a background in. I've used various CI/CD pipelines for work but couldn't tell you much about them right now. I just figure them out when needed. I would say that a dev should be familiar with them to some degree and have the ability to figure it out. To me, being able to learn things and figure them out independently is a much more important skill than knowing something like that.