Best CI/CD Practices for Startups: Tools, Pipelines and Deployment

I'm seeing things like CI/CD and Github Actions being required knowledge for a lot of entry level roles. What are hiring managers even looking for regarding these? How much knowledge should an entry level person have with these things? Is it enough to make a project that has a CI/CD workflow?

I'm deep-diving into DevOps to bolster my resume. I've spent the last few weeks wrestling with Jenkins and Sonar on a home lab, but I’m noticing a massive shift toward GitHub Actions in recent job postings. If you were hiring a Mid-Level dev today, which would impress you more?

Is knowing Jenkins and its complex ins and outs like Groovy pipelines, node management, and plugins worth it to most companies? What about osmeone hwo is not so proficient with Jenkins but has a lot of experience with Github Actions (or maybe even Gitlab and Bitrise CI/CD)?

Is Jenkins only for legacy maintenance or is it still a core requirement for Big Tech and startup infrastructure?

I haven't worked with, or really even heard about, Jenkins in 10 years.

Maybe I'm living in a bubble, but Jenkins to me screams legacy enterprise.

In my experience, companies are using whatever CI solution their git provider offers. If you're using GitHub, GHA is the way to go. If you're using GitLab, go for GitLab CI. If you're using Bitbucket, use Bitbucket Pipelines. And if you ever change your git provider (which happens more often than it should)? You change your CI/CD platform with it.

But really, if you know one of those, you know all of those. GHA isn't drastically different than GitLab CI. When companies want experience with CI/CD, they moreso mean the general concept and implementation of it, and less the specific tool. E.g. what are best practices for those pipelines, instead of "how do you do [hyper-specific syntaxy thing] in [hyper-specific tool]".

Hi, I'm working in a small business and we want to start automating our build and test. We are currently using Jira for our issue management and the plugin XRay for the manual test.

What would be the best place to start for automation

#Edit: We are using GitTea and it's a mainly C# project

#Edit 2: All our server are hosted locally with no cloud involve

#Edit 3: We are deploying on an embedded platform with a web page to configure it

#Edit 4: I have a set of devices in our QA lab ready to be deployed on at a moment notice for automated testing, they are usually used for long run but we usually do a stabilization period before a long run begin.

Ignore other comments that are trying to get you to use Gitlab or Jenkins or whatever, it doesn't matter at all. Some tools are better than others but I wrote automation in bash 15 years ago and it got the job done.

The important thing is what you can do with it and how you're gonna sell it to the team which may be very unhappy if you just tell them to wait an hour for everything to run after a push.

1) Use a linter and code compliance tool so the devs don't need to manually check if braces are in the rights place during the code review

2) Automatically build packages instead of having the devs build them

3) Automatically update dependencies and run unittests each day so the devs know in advance when something breaks

Tools are just tools, grab a copy of Devops Handbook and research the ideas behind automation instead of trying to find the best tools.

Hi all. I'm a new graduate currently working on a couple personal web development projects to bolster my skillset for software engineering. I'm still applying for work, so these projects are primarily meant to make me a more attractive applicant. I just finished one, a web game built in Java with some simple JavaScript and HTML/CSS for the front end. I'm now looking to host the game so that I can show it off, and was wondering if it would be worth it to use this as an opportunity to learn some CI/CD skills.

The game is pretty much completely finished, and I doubt that I'll be updated much in the future, so a lot of the actual benefits of a pipeline are kind of lost. I also plan to move on to a project that explores some distributed systems concepts once this one is being hosted, so spending more time here will take away time spent learning about that.

For further context, most of my internship experience was focused on data science and ML. My most recent involved building a couple of basic apps, but these projects are my first exposure to web development, and I would like for them to cover as many skills as I can without making it seem like I've spent too much time on breadth of knowledge rather than depth of experience.

My understanding of how most developers interact with CI/CD pipelines is that they're primarily using them, rather than developing them themselves; that part is mostly done by the DevOps team. With that in mind, is it worth spending the time to implement a CI/CD pipeline from scratch in this situation? Specifically, is it worth the time trade-off versus focusing on the distributed systems project? And if so, does anyone have recommendations for a simple pipeline design which would let me get the experience of having used one without needing to spend terribly long developing it?

Thank you!

I was thinking about using jenkins? Is that still widely used?

We use CircleCI+argocd+jfrog now but kinda miss using github actions.

What are the Best Practices every newcomer to CI/CD should know about? Which advices would you give to a beginner?

​

Edit: What advices would you give to the yourself of 5-years ago?

I am working with JetBrains TeamCity since four years and use it on my company and also for my private projects. It's easy to configure and has a great support.

Avoid doing too much in your CI/CD pipeline. I once built a gitlab pipeline that would get the commit messages between the new and previous tag and compile release notes by fetching issues from JIRA. In hindsight that was too much, there was no reason my build pipeline should have to rely on all that logic, and it was hard to maintain. Just keep it simple with a few cases (what happens on master? what happens on dev branch? what happens on tags?)

Use declarative pipelines where the pipeline definition is committed in the git repo so devs can see it, understand it, fix it. Don't just call scripts/functions that just result in an extra codebase to maintain. For Jenkins especially, don't bother with writing Groovy scripts. Nobody wants to work with Groovy. Just use shell/bash steps. It's very frustrating for a developer when their build is failing but they don't know why and can't fix it because the build logic is decoupled from the app repo and changing it could affect other projects. pipeline logic should be isolated to just the app that it builds.

Docker agents/runners are a great way to get flexibility without having to keep a bunch of runner hosts synced with dependencies/binaries. Gitlab and Jenkins both support the pattern. essentially you run your pipeline steps in a container that you specify in your pipeline declaration, so you get whatever binaries you need from the container image and it doesn't have to be installed directly on the host.

Think about reducing clutter in your artifact repositories. If the commit isn't on master, you don't need a whole new artifact version in your registry, just use a floating version for the latest commit to the dev branch so it can be pulled and deployed.

Build your pipeline so it can be easily tested in a dev branch with minimal changes.

Remember forks and build that case into your pipeline. If there's step you only execute on "master", make sure it's also not running "master" in a forked repo.

Hi everyone,

​

I'm finally done with a fresh new infrastructure on AWS with several cluster k8s and a central private gitlab that I now want to use for CI/CD.

​

I manually did my first tests by implementing a `.gitlab-ci.yml` and a creating a related chart. The pipeline run and my deployment is done. Nice.

​

I now have to configure the pipelines for all my other services and… I have a lot so I'd like to have your best practices to avoid any useless repetition and to avoid my developers to have access to this configuration.

​

So my first idea is to not host my helm into the repository but to have a independant private helm repository wherefrom I will install/upgrade my charts. At least, this will be hidden (somehow) and I can use templates for me to reduce the amount of repetitive code.

​

but what about the `.gitlab_ci.yaml` ? I have for example generic jobs that I always want to run (validation, security_check, build/push/tag/...) How can I manage this ? And is there a way to have the strict minimum in the repo and to keep a larger part somewhere else (as I will do for the charts) ?

​

thanks for your inputs !

​

++

GitHub actions. Don’t bother with Jenkins anymore. Jenkins is /fine/ but it’s dated and getting phased out

For CICD, I think Azure DevOps is easier to start than Jenkins. And they do the pretty much same job.

You need to be doing CI to actually get the benefits. That’s “Continuous Integration”, meaning you merge in with everyone frequently (multiple times a day). Trunk-Based Development is effectively a prerequisite for CI, which is a prerequisite for Continuous Delivery, which is a prerequisite for Continuous Deployment.

Most companies just do automated deployments without the CI part, and call it CI/CD, and wonder why their deployments are fast but their development rate isn’t.

Hi - I just started a new role as an admin for a small-ish bank. We haven't implemented yet, but are getting our ducks in a row to kick off the project soon. My manager expressed that CI/CD is what he's most nervous about. He is considering Gearset down the road.

In my past experience, I was at an even smaller bank and, for all intents and purposes, the only part-time admin. I only have experience with the native change sets and Developer Sandboxes.

Is there a good place in the community to review CI/CD best practices? I'm curious for any helpful advice anyone is willing to offer as I research and prepare... thank you!

I wanted to improve our CI/CD pipeline since right now we are a small team working a web application with a frontend and backend and we are doing everything pretty much manually.

The idea I have so far is have 2 persistent branches, main and prod.

• The main branch contains everything that we want to deploy next
• When we want to create a new feature we branch off main and once the feature is done and ready to be deployed is merged back to main using a PR request.
• Anytime something in the main branch changes our CI/CD pipeline (AWS CodePipeline) will build the docker image, run tests and deploy it to our staging server.
• After checking that everything works as expected in staging we can merge into production which does pretty much the same but deploys into production server/servers instead.
• If we have a bug in production we can create a hotfix branch where we fix the bug, this gets merged back into main to test it in the staging server and if everything works well the hotfix gets also merged into production (not sure about this part here since the fix will be tested in staging next to a lot of unreleased features, in this case staging is not a 1 to 1 with production)

If we want to avoid having the staging pipeline being triggered all the time (for example we are adding a lot of features and we dont need to see them yet in staging) we can implement a manual check in our pipeline that we have to click on to build and deploy into staging.

What do you think, does this sound like a good way of doing this?

In a different post someone suggested only having 1 main branch and "promoting" the stage build into production. But i have no idea how to do that.
Also, we have different AWS accounts for stage and prod, so not sure if that will even make it more difficult.

You only need the one branch. Just like you were going to have a manual check before staging, you just extend that same pipeline with another manual check and the prod deployment. You basically replace that second merge with the manual check as an approval gate.

Shouldn't be an issue deploying to multiple accounts. I commonly put the pipeline in a 3rd account and cross deploy to the other two.

imo all these types of flows connected to specific branches eventually create contention - you want your development, test, and deployment to be mostly lockless; it just scales better.

In the past, I've had one prod deployed from main (chatops style) and many testing environments - one per dev/qa that they can deploy with whatever they're working on - a feature or perhaps a release branch.

Feature branches are cut from main, and eventually squash merged to main before deploy - so they can be easily reverted as a single commit if something breaks. Automated testing and builds happen on all branches; feature branches refresh from main periodically to track changes as other projects go out.

The main goals were fast deploys and having a human on the keyboard when they happen, and not having people contend for the same resources - branches, environments, etc. Most significant development happened locally - devs could run the whole stack on their laptop.

I have been advocating this workflow and have a design in mind. Can share it with you but it's untested as yet. That said it's quite straightforward to implement. Challenge will be in getting the team to adopt it and have the discipline to follow the process.

Hello everyone ,

I am in charge of managing our CI/CD at a small startup company.

Recently we deployed our CRM in AWS.

CRM is used by the company users only.

So there is a Pipeline that building a docker image and deploying it on a Fargate ECS (master branch when it is pushed) .This is our production environment.

Because the company is extra tiny, if we fix a bug,we have to deploy it fast so the users can continue working.

Before AWS/Cloud we had a server running locally with 2 docker containers inside.One for Dev and one for Production.So we could make changes in dev container instantly(ready to use for our users)

If we fix a bug(important to our internal business processes) we should guide our users to use our dev app and then we schedule to merge it with production.

Now in the cloud how can we setup a Development app without building a docker image ( that is taking too long) ? Only for the development app, so users can access our dev app in the cloud with our hotfixes and changes if it is necessary.Our production pipeline will continue as it is.

I'am sure that it is not the best practice for CI/CD,but we have to work this way.

Thank you for your help.

I'm researching CI/CD pain points for JS/TS developers and want to understand what real problems people are facing (vs what I assume they are).

Whether you're using GitHub Actions, GitLab CI, CircleCI, etc, what parts of your CI workflow still suck?

Things like:

• Setup and maintenance taking longer than it should
• Dealing with failures and debugging what went wrong
• Keeping configs in sync across multiple projects
• Costs adding up faster than expected
• Anything else that wastes your time

Or maybe you've got it locked in and there aren't really problems left to solve? That's useful to know too.

What's your experience been like?