Continuous Integration best practices

It's good practice to follow these best practices for CI:

•  Maintain a repository: To manage a source code repository or master repository, you have to use version control systems. This system will help to manage different versions of the files and provide a history of the code. A master repository will be the buildable code from a fresh checkout and it doesn't require any additional dependencies. This repository contains the working version and all the changes should be integrated in this repository. You can also place the build server to monitor the code changes at any given time.
• Build automation: A single command is capable of building the entire system. The team should standardize the build script or build tool to trigger the build from the command. This build automation includes automating the source code integration, code compilation, unit and integration tests, and deployment on a production-like environment. You also need to keep a backup of the previous build in the version control system. If there is any failure on the build, then it can be reverted anytime to the previous versions, and the source code can be compared to find the reason for the failure.
• Make a self-testing build: To catch defects/bugs rapidly and efficiently, you have to include test automation in the build process. The result of running that automated test suite will give you information about any failed tests. If the test fails, it will fail the entire build.
• Everyone commits frequently: It will reduce the conflict if the developer commits regularly. It is good practice for CI if the developer commits changes at least once a day or several times a day. By doing this, the developer will see the real-time state of the test and health of the application.
• Build from every commit: A team gets more tested builds using frequent commits. It means the main repository will stay in a healthy state. There are two main ways you can do the build. One is a manual build and the second is using a CI server.

In a manual build, the developer kicks off the build on the Integration machine, using the main repository source code.

A CI server will monitor the repository. If there are any commits that have happened on the main repository, it will automatically check against the repository and start the build, and notifiy the result to the committer of the build.

• Broken builds fixed immediately: As a part of the CI, if any build fails, it should get fixed immediately. It means there should be the highest priority to fix the build. The fastest way to fix the build is to revert the code from the last known good build.
• Faster build: The build should be very fast, so if there is a problem with integration, it can be quickly identified. If it is more than 10 minutes, then the process becomes dysfunctional as people won't commit frequently. A large build will be broken into multiple small jobs and they will be executed in parallel.
• Test on a clone of the production environment: The production environment may differ from the test environment, so it might happen that a build on the test environment works properly but it will fail when deployed to the production environment. It will be costlier to create a replica of the production environment, so it is better instead to create a pre-production environment (staging). This environment is not tightly regulated but it has the same versions of the operating system, software, patches and libraries. In that way, the build will go into  actual production without any dependency issue.
• Latest deliverables available easily: The team should know the latest build location. It's a good practice to keep the recent builds in the same place. It will help to do the early testing with the stakeholders and/or testers, to reduce the chances of more defects after deployment, and if errors are identified at the early stage then these can be fixed quickly.
• Latest build results available for all: Build information such as start/finish and its results, such as success/fail information, can be communicated with the team through email or the website, so that everyone is aware of the current situation. If the build fails, then it will notify the development team to take speedy action.
• Deployment automation: Deployment automation helps to deploy the build into production easily, by running the build on a local environment. As tests are executed on the staging environment, this deployment automation requires a minor increment in effort.