Builds can be nasty beasts when It’s finally time to organize and do them.

There are so many things you did not think about, that it can take days or weeks to come up with a build for an existing system. To avoid the nastiness, start with an empty build, on the first day of your project. Then grow it gradually.

Before you start your first feature on a product that you know needs to exist for a long time, start with creating the pipeline for deploying it.

• Create an empty source project. Something that is a stand-in for the real project you are about to develop. If it is a web application, it could be a single page with “hello world” on it. This project will be what you throw through your empty pipeline to test it.
• Create a simple CI build script that will live with the code. For now it might only compile your empty project. Make sure it is relative to the code location so you can run it anywhere.
• Create a simple “Deploy to production” build script that lives with your code. For now this will only copy your project or put some file somewhere on a production server.
• Oh, you should have a production server to deploy to, so you can deploy your product. that is step #1  of the first iteration!
• Create a new project in your CI system (I use teamcity, but go ahead and use Jenkins or anything else you desire. ) In that project create a CI build configuration that triggers the CI build script, and a Deploy to Prod Configuration that triggers the Deployment build script you wrote.
• Connect the CI server to your source code repository, and make it trigger the CI on commit.
• Make the CI artifacts available to the Deployment configuration.
• Make the Deployment Configuration trigger automatically on a successful CI build.
• Run the whole thing and see a “hello world” in production

Now you are ready to nit pick:

• You might want to create a “deploy to test” configuration and script that triggers instead of production.
• You might want to do the same with a staging environment

Now you have an empty build and deploy pipeline.

You can start writing real code, and as real code gets created, you only need to start doing small modifications to your build scripts , or CI process variables to make things work nice and smoothly.

Now the build grows and flourishes alongside the source code, instead of as an afterthought. and it is remarkably easier to handle because the changes are much smaller.