Hacker News new | ask | show | jobs
by bob1029 1864 days ago
We only use GH Actions for check builds right now, which are easily disabled as a temporary measure.

Having the ability to build & deploy your software outside the confines of a cloud vendor is essential to survival. When the automation works, its great. When it doesn't, have a manual process that you can follow on a local workstation.

At the end of the day, you can always email the customer a zip file and walk them through installing the update in production. That is, as long as you didn't make your architecture and CI/CD one in the same thing, in which case you probably need to hit the reset button and try again.

1 comments

Great advice. How is this managed where you are? Do you share the same code between CI and the local workstation?
Everything required to build our application lives in a single code base & Visual Studio solution. The application is capable of building itself from source.

If you know how to do things like Process.Start, there's really no excuse for not being able to automate your build processes using code. MSBuild has a pretty damn simple set of CLI args if you are just doing modern .NET 3.x/5.x apps.

  git clone <my repo path>
  cd <my repo path>
  dotnet build --configuration Release
  //copy build artifacts to where ever they need to go
That's about it for us.

We use SQLite, so there aren't any dependencies outside of any particular checkout of the repo.