Hacker News Reader

Comment by OliverGilan | Hacker News Reader

This article addresses an issue I currently have but doesn’t actually address how to fix it. I recently set up a simple homeserver to use as a testing ground for sideprojects before eventually porting them to a cloud service.

As a result I looked into building a CI/CD pipeline for the first time and practically every article I came across talking about “CI/CD” really just talked about CI.

Even today I have no idea how to easily automate deployments. The only service I know of that does this is Heroku. Ideally I should be able to push any changes to a master branch on Github and have those changes automatically deployed to my server. How this can be done is poorly documented from my experience and certainly nowhere near discussed as much as CI solutions.

View on HN

I implemented CI/CD pipeline for a project I am working on recently. I used Azure DevOps and the app is self-hosted on our servers. It took some time to figure out but I got it working after some trial and error.

Right now, it is triggered by a push to "master" branch, the pipeline builds the app, runs tests, creates artifacts(files to be used for release/deployment). Then, the release pipeline is triggered, this builds a "release", and deploys the application to "staging" environment used for user testing. Once, the application is approved, I have to go to Azure DevOps and confirm deployment to "Production". There are many different approaches, triggers and settings.

Check out Azure DevOps they have a lot of good information on CI/CD pipelines.

In our production system, CircleCI has Github and AWS credentials. When CI is done building and testing the Docker image, it pushes it to a private container registry and updates the terraform infrastructure repo with the new container hash ID (either through a tfvar file or through env variables). Then another CircleCI job runs `terragrunt apply` in that repo to deploy to staging (prod/stage/dev are separate folders, automated jobs only update staging). Deploying from staging to prod is manual, by copying the container hash from staging to prod and pushing to master.

That's because building software & running tests is somewhat standardized, but deploying is very specific to each application's environment (and requires additional credentials, integration with monitoring, automated rollback, etc).

Some platforms provide this as part of their feature set (like AWS).

You talk about your side-projects - how do you deploy them today? Write a script for that and think about how many unique-to-yourself edge cases you are handling. If you believe your solution is generic and re-usable, then build that into a tool/platform for everyone and profit!

The key word that covers the Heroku-style experience is "GitOps".

Most tools are Kubernetes-centric (i.e. FluxCD[0] or Jenkins X[1]), but there are some simpler Docker-only options as well such as Dokku[2].

[0]: https://fluxcd.io/

[1]: https://jenkins-x.io/

[2]: http://dokku.viewdocs.io/dokku/

>As a result I looked into building a CI/CD pipeline for the first time and practically every article I came across talking about “CI/CD” really just talked about CI.

You don't mention what technology you are using, but maybe you didn't find the correct resources?

https://codefresh.io/docs/docs/yaml-examples/examples/#deplo...

F.D. I work for Codefresh

In my hobby project I just have a script that pushes docker images and rsync the files (docker-compose.yml and some volume mounted things), and then sshes to the server and restarts docker-compose.

where would you like to deploy? I've never had this problem you mention, but I knew how to deploy manually before using CI/CD, the problem if any is usually how do you translate what you are already doing to deploy manually to the CD format/language and mechanism.

EDIT: I subscribe what jasonpeacock is commenting above, I think it's better expressed in those words.

Reply on news.ycombinator.com