What is it?
Continuous Integration (CI) is a way to make sure that your solution is running and is at a good state at all times. The main purpose of CI is to make sure latest changes/updates to code are syntactically correct and, if implemented correctly, semantically correct right after the new changes have been added to the shared code repository. This helps us keep our solution healthy at all times, exposes issues early in the process and so reduces testing/bug fixing time.
Another major advantage of using CI is preventing or reducing integration problems. New changes always pose a risk of not working well with other modules or parts of the solution. CI tries to expose these problems as early as possible.
Keep in mind that it is extremely difficult to be able to prevent all problems whether they’re syntax, semantics or integration issues.
Two aspects of CI
1) Development practices
These involve changing the way developers develop and submit their code, the way the solution is structured and sometimes they way they do things. There are lots and lots of practices for a better CI integration. Each solution, developer or development company may have their own different practices and standards. However there are set of main practices that their existence is very preferable:
- Having a shared code repository where all the code is stored and used to pull and push the code on a daily basis (not just a backup option).
- Committing and pushing to the shared repository at least daily (some even believe in doing that several times a day). Code chunks would be smaller and easier to deal with and with problems that may arise.
- Create lots of unit tests. The more unit tests (that are well designed) the more semantically accurate solution you can have. Make sure to plug your tests to a single method or call in order to be able to test everything with a single click.
- Do not put environment specific settings directly in the config files. Instead create config files templates that could be used to create the actual files for each environment with its specific environment values. We’ll talk a bit more about this later on in the series.
- Provide a separate test machine identical to the production environment to deploy and test on.
- Automate the build process on the new test machine. There are tools that can simplify this. We’ll talk a bit more about this later on in the series. The build process must include building the code, running the unit tests, creating the config files from their templates and informing everyone involved about the results.
- Having frequent builds or after each code push in order to provide feedback as soon as the developer has completed the task.
- Deployment to production should be automated too and as close a process to the test build process.
These help developers and build managers preserve the stability and quality of code at all times. If you search for CI tools you’ll probably find lots and lots of them. Some are easier to use, some provide more features and some may cost lots of money. CI tools can be the best tools you use for your solution. They make building/deploying solution extremely easy and sometimes a matter of a single click. So they are extremely important and worth your time to research and setup. Again different tools provide different functionality but in general you can configure them to:
- Automatically pull from your shared code repository, then
- Build your config files templates, then
- Run your unit tests and provide you with the results, then
- Build all your projects and send you the results including the code the broke the build and who was responsible for that commit/push
- Run the build process automatically every several minutes, after each push, at specific times of the day, at night etc…
These are just some of the features. Plus most tools provide ways to integrate plug-ins which provide endless numbers of features and you can always use a combination of tools (if you must).
Notes on CI with Sitecore and Helix
- You can create a Sitecore project using a shared instance of Sitecore DB, but this is not the best practice. One developer may test something and affect or ruin other developers’ work. So it is recommended to have a local instance of Sitecore on each developer’s machine. To do this, developers will have different configurations according to their local machines and having this, environment-specific configurations committed and pushed between the environments will mess other developers’ configuration. That’s why Sitecore projects rely on a CI tool or at least a config file building tool.
- Sitecore/Helix projects use tools to serialize Sitecore items into files such as TDS and Unicorn. Each developer is responsible for syncing the local Sitecore instance with the latest updates after each pull. A CI tool can incorporate external tasks that could achieve this automatically and so reduce the developer’s input.
- Helix projects have a structure where each feature is implemented in a separate project. These projects should not be added as references to the main Web project. This results in a need for another way to publish those feature projects. Visual Studio’s publish tool only publishes a selected project with its referenced projects. In Helix this will not work. To fix this we need a CI tool to publish all projects under the solution folder on every build or publish action.
At the end of the day everything can be accomplished without any tools (maybe with extreme difficulty or with painfully long steps). However, once you try CI tools you will not be able to forget them.