A lot of times applications are deployed by hand on a developer’s laptop. That can be time consuming and it is mostly done by one, or a few developers within the team.
With a build server, you know you have an independent build, unit tests & code analysis checked (if set up) and a package that can be tested by the test team, if deployed.
If the application has had some releases, it is set up for manual builds and deployments. When that is in place, the application must be adjusted for a build and deploy server. For example, the transformation of the configs now needs to be done at deploy time instead of at build time; that is because the package from the build can potentially go from test all the way to production. When done manually, it is built for a specific environment. That also means that when a version is approved by the test team, a new build needs to be made for the acceptance environment; the same for production.
From the Start
So, how to smoothly implement this? Well, when there is little to nothing to integrate: at the start of the project.
With no history, it is easy to configure and the application is setup correctly from the start. The CI setup can grow with the application, although probably little to no changes are required. And every team member can do a deploy.
Octopus Deploy is particularly easy to use, non-developers can also do a deployment once it it set up (for .Net projects)
Some options for build servers are:
- Team Foundation Server (TFS). Depending of the version, it might need an upgrade (Compiler version / .net framework version)
- A hosted build server AppVeyor
- An on premise option is Bamboo
Unit test basics
Another good thing to setup from the start is the unit test basics. Setup the use of a fake database with dependency injection and make some unit tests that can be used as examples.
For Sitecore projects, these are good blogs:
- Isolating calls to Sitecore.Context for improved unit testability – Part I: ItemProvider, Moq and FakeDb
- Improving unit test readability: helper methods & named arguments
To share the code and knowledge of the application and it’s changes, do peer reviews between developers of a feature. It also triggers discussion about the way of coding, to improve the coding guidelines and uniform coding.