I was reading the Continuous Integration by Martin Fowler article yesterday, the article is from 2006 but I think it is still very applicable today, the statement around a single command stuck in my head.

Automated environments for builds are a common feature of systems. The Unix world has had make for decades, the Java community developed Ant, the .NET community has had Nant and now has MSBuild. Make sure you can build and launch your system using these scripts using a single command.

A common mistake is not to include everything in the automated build. The build should include getting the database schema out of the repository and firing it up in the execution environment. I'll elaborate my earlier rule of thumb: anyone should be able to bring in a virgin machine, check the sources out of the repository, issue a single command, and have a running system on their machine.

The concept sounds great but with my limited working knowledge of Azure Pipelines for Continuous Integration builds it feels counter-intuitive to not use the tasks available in Azure Pipelines and have this run a single script that we wrote.

On the flip-side it doesn't make sense to just have a build definition in Azure Pipelines as being able to use the same build definition locally during development is useful.

I would guess the same applies to other applications offering CI functionality where the build pipelines do not support being reused locally. I read that GitHub Actions can be executed locally, perhaps that is the exception?

How is continuous integration done in the real world to allow builds to be done locally and on the CI server?

For context I am working with Microsoft solutions/projects i.e. .csproj, .sqlproj

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.