Answers: <p>I would recommend reconsidering configuration-as-code (what you call code-hosted CICD config) this is considered best practice all over the place. The advantage is that you set up your tools to point to your repo and it &quot;just works&quot; - this provides a single point of truth as well as &quot;easy&quot; (read: easier than having to reconfigure all jobs manually) disaster recovery.</p>
  <p>The only downside is that you have issues if you update the pipeline without wanting to push code changes to your prod branch, but only hits you if you want to do roll-backs. Besides - you can always pull the file to your production branch with <code>git checkout feature/otherbranch -- Jenkinsfile</code></p>
  <h1>Jenkins:</h1>
  <p>I use Jenkins for some of my own projects and have a setup that almost sounds like what you want (Except I build on all pushes, and deploy based on separate config in a separate repo.) these comments are based on that I even have a <a href="https://github.com/JoSSte/PHPDummyApp/blob/master/Jenkinsfile" rel="nofollow noreferrer">demo project on github you might want to gather inspiration from?</a>.</p>
  <p>You can always put your pipeline config in a separate repo and write code to manually check out the code, but this means that you have to either have THAT job polling the first branch often (to emulate triggers that work out of the box if you keep to a single repo)</p>
  <p>Alternatively you can eliminate the second repo by manually configuring a pipeline in Jenkins, but you have to create one for each branch (you miss out on the goodness of multi-branch pipelines - again I'd advise you to reconsider the configuration-as-code approach)</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-01-02T07:31:19.033Z
Answers: 2023-01-02T07:31:19.033Z
Answers: JoSSte
Answers: <p>In <a href="https://github.com/theonedev" rel="nofollow noreferrer">OneDev</a> the Pipeline can be configured in a GUI. See <a href="https://github.com/theonedev/onedev#a-full-fledge-cicd-engine-without-writingyaml" rel="nofollow noreferrer">here</a>.</p>
  <p>But I'm not sure if this is the right tool for you, because it is a git Server with CI/CD included.</p>
  <p>But maybe it is possible to set up a mirror (which might complicate things).</p>
  <p>Or you completely switch to onedev, which might be risky.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-02-02T11:47:03.200Z
Answers: 2023-02-02T11:47:03.200Z
Answers: Uli Sotschok
Body: <p>I work for a small startup. We have 3 environments (Production, Development, and Staging) and GitHub is used as VCS.</p>
  <p>All env runs on EC2 with docker.</p>
  <p>Can someone suggest me a simple CICD solution that can trigger builds automatically after certain branches are merged / manual trigger option?</p>
  <p>Like, if anything in merged into dev-merge, build and deploy to development, and the same for staging and pushing the image to ECR and rolling out docker update.</p>
  <p>We tried Jenkins but we felt it was over-complicated for our small-scale infra.</p>
  <p>GitHub actions are also evaluated (self-hosted runners), but it needs YAMLs to be there in repos.</p>
  <p>We are looking for something that can give us the option to modify the pipeline or overall flow without code-hosted CICD config. (Like the way Jenkins gives the option to either use Jenkins file or configure the job manually via GUI)</p>
  <p>Any opinions about Team City (Self-Hosted Community Version)?</p>
  <p>PS: We are looking for free and self hostable options only!</p>
  
Comments: CC BY-SA 4.0
Comments: 2023-01-02T07:23:21.297Z
Comments: Why do you not prefer configuration-as-code (what you call code-hosted CICD config) this is considered best practice all over the place.  
  There are downside is that you have issues if you update the pipeline without wanting to push code changes to your prod branch, but only hits you if you want to do roll-backs.
Comments: JoSSte
Comments: CC BY-SA 4.0
Comments: 2023-03-05T07:04:12.407Z
Comments: `after certain branches` there is the reason you need a bit of code.
Comments: Thorbjørn Ravn Andersen
Comments: CC BY-SA 4.0
Comments: 2023-03-06T07:55:40.413Z
Comments: That said, Github Actions can do quite a lot.  I would start there.
Comments: Thorbjørn Ravn Andersen
Tags: <docker><cicd>
Title: Simple CICD workflow for small-scale deployments?
UserDisplayName: Atharva Unde
ThreadText: # Simple CICD workflow for small-scale deployments?
  
  (Asked by: username_0 on 2023-01-01)
  
  I work for a small startup. We have 3 environments (Production, Development, and Staging) and GitHub is used as VCS.
  
  All env runs on EC2 with docker.
  
  Can someone suggest me a simple CICD solution that can trigger builds automatically after certain branches are merged / manual trigger option?
  
  Like, if anything in merged into dev-merge, build and deploy to development, and the same for staging and pushing the image to ECR and rolling out docker update.
  
  We tried Jenkins but we felt it was over-complicated for our small-scale infra.
  
  GitHub actions are also evaluated (self-hosted runners), but it needs YAMLs to be there in repos.
  
  We are looking for something that can give us the option to modify the pipeline or overall flow without code-hosted CICD config. (Like the way Jenkins gives the option to either use Jenkins file or configure the job manually via GUI)
  
  Any opinions about Team City (Self-Hosted Community Version)?
  
  PS: We are looking for free and self hostable options only!
  
  **Tags:** docker, cicd
  
  > **Comments:**
  > **username_1**: Why do you not prefer configuration-as-code (what you call code-hosted CICD config) this is considered best practice all over the place.   There are downside is that you have issues if you update the pipeline without wanting to push code changes to your prod branch, but only hits you if you want to do roll-backs.  
  > **username_2**: `after certain branches` there is the reason you need a bit of code.  
  > **username_2**: That said, Github Actions can do quite a lot.  I would start there.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2023-01-02. Score: 1
  
  I would recommend reconsidering configuration-as-code (what you call code-hosted CICD config) this is considered best practice all over the place. The advantage is that you set up your tools to point to your repo and it "just works" - this provides a single point of truth as well as "easy" (read: easier than having to reconfigure all jobs manually) disaster recovery.
  
  The only downside is that you have issues if you update the pipeline without wanting to push code changes to your prod branch, but only hits you if you want to do roll-backs. Besides - you can always pull the file to your production branch with `git checkout feature/otherbranch -- Jenkinsfile`
  
  # Jenkins:
  
  I use Jenkins for some of my own projects and have a setup that almost sounds like what you want (Except I build on all pushes, and deploy based on separate config in a separate repo.) these comments are based on that I even have a [demo project on github you might want to gather inspiration from?](https://github.com/username_1/PHPDummyApp/blob/master/Jenkinsfile).
  
  You can always put your pipeline config in a separate repo and write code to manually check out the code, but this means that you have to either have THAT job polling the first branch often (to emulate triggers that work out of the box if you keep to a single repo)
  
  Alternatively you can eliminate the second repo by manually configuring a pipeline in Jenkins, but you have to create one for each branch (you miss out on the goodness of multi-branch pipelines - again I'd advise you to reconsider the configuration-as-code approach)
  
  
  ---
  
  ### Answer by username_3 on 2023-02-02. Score: 0
  
  In [OneDev](https://github.com/theonedev) the Pipeline can be configured in a GUI. See [here](https://github.com/theonedev/onedev#a-full-fledge-cicd-engine-without-writingyaml).
  
  But I'm not sure if this is the right tool for you, because it is a git Server with CI/CD included.
  
  But maybe it is possible to set up a mirror (which might complicate things).
  
  Or you completely switch to onedev, which might be risky.
  
  
  ---
  
  