Continuous Delivery
At DevCore we are actively working to ensure and enhance the quality of our deliveries. High delivery quality, of course, also depends on planning, project management and development processes, here we will concentrate on telling on how to change our release processes.
We strive for our projects to embrace continuous delivery, which means short release cycles with automated builds, tests and production sets. The point of automating as much as possible is that the release process becomes predictable and repeatable, which, in turn, saves time and minimizes human errors that may occur in manual steps.
Version management is a prerequisite for tracking code changes over time and keeping parallel development trails at the same time. We have used Git to handle our source code, but now we have also standardized our branching strategy and how it relates to different release channels and lifecycles.
We have previously used the Team Foundation Servers
We have previously used the Team Foundation Servers (TFS) XAML Building System to automatically compile and run tests when entering new code. Now we migrate our buildings to the new construction system in TFS 2015 which is more powerful and modular. With the new construction system, we can now, directly on the building server, easily drive everything needed (code compilation, sass compilation, sprite generation, npm, gulp, etc.) to put together a deployable package. Previously, developers needed to create this package locally on their development computer, which could create problems because you do not have a consistent building environment.
Now we can also run more tests and analysis tools
Now we can also run more tests and analysis tools to speed up any problems. The fact that the building server can run preprocessors for e.g. javascript and css, we no longer need to check the performance files, so now we need unnecessary annoying merge conflicts when multiple developers work together.
In terms of deployments of what has been built, we have previously done it through MS web deploy in our internal testing environments, but since web deploy has some limitations, we have made production sets through manual file copying. Now we have acquired Octopus Deploy to handle all deploys regardless of the environment. With Octopus Deploy, we get a release pipeline where releases are printed directly from the building server. The release pipeline has different steps, one for each environment to be deployed to. How many steps it takes depends on projects but usually there are 2 or 3 environments (development / testing - staging - production).
The changes we made make the job easier
With Octopus Deploy, the release is only built once, which assures to deploy exactly the same files regardless of the environment. After testing has been completed in an environment, you can easily advance the release to the next step with a button press and Octopus Deploy manages everything automatically. Transformations for configuration files that deal with differences between environments are applied at deploy instead of building as is the most common.
In addition to making releases faster and more robust, Octopus Deploy provides TFS with total traceability between environments, building server and source code. There is no doubt about which code is running in an environment as you can quickly see exactly which unique version number is deployed and what build and version of the code it corresponds to.
The changes we made make the job easier, more efficient and safer for our developers and we are convinced that it will be reflected in business value for our customers.