PICTURE-PERFECT PROCESS

Continuous Delivery. The major goal of continuous delivery processes must be to shift the “aches” further to the left, i.e. to the beginning of the pipeline, in the direction of the developers.

The earlier there is a unique version in a defined state, the less complicated even complex deployments become. Especially in an agile environment like Spryker, a build server can generate the desired left-swing.

In the basic constellation, a Spryker release goes through various processes: From Git to Composer and npm to webpack or other frontend compilers to code generators at the end of the toolchain. This whole process is time-consuming and has a number of dependencies on external resources. In addition, the results of many tools are version dependent. A build that was successful on one tier/stage can fail on another system, or – even nastier – have deviations that are not immediately noticeable.

Similar questions arise over and over again: Do all developers and stages have the same version of the tools? Do they all work on an identical setup of their development environment? What does it look like on the server? Are the external resources available? These questions become obsolete if you include a build server in the continuous delivery process.

Why?

A build server enables small-scale, atomic deployments, since the release is available in one piece and is not created during the release process. It is also possible to switch directly to the latest release. Since no further build tools are used on production environments, no new dependencies arise during deployment on external registries and the results of the tools themselves. The unique version of the build artifact then forms the basis for further testing and customer communication. Identical setups of the other tiers or stages, such as a preview environment followed by the production system, thus ensure that problems already fall on the developer’s feet in the dev environment and are fixed at an early stage so that no new problems can be created by the build process.

What?

What the build server ultimately presents as an artifact is very flexible. From tarball to Debian or rpm packages, containers to complete VMs, everything is possible.

But beware: You have to make sure that configurations with environment variables such as different URLs or databases of different stages are handled dynamically in the build and can be parameterized from outside. For this reason, you should also clarify responsibilities at an early stage with regard to the following aspects:

• When is the hoster in charge? (entrances, paths, etc.)
• What is the developer’s responsibility (e.g. interfaces to ERP or Google Analytics etc.)?

You should also separate the configs – the hoster config comes over ENV, everything else is part of the project in git! This is the only way to ensure that there can be an identical build for all environments.

How?

The build server’s toolchain can take many forms. You can choose your favorites for the builds: Shellscripts, psh (php shell helpers), rocketeer, deployer, capistrano grant, gulp … The tools should be part of the project, so that they are versioned in the repository or kept on a consistent level via versioned dependencies.

A build service, including ticketing, can easily be set up as an agency service, even if corporate customers in particular would like to have their hands on it in order not to become too dependent or to operate a multi-agency setup. The flexible build pipe is also very helpful in this case, in particular to be able to play on different platforms such as Jenkins, Bamboo or Gitlab.

Bottom line