And there is more.
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.
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 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.
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.
A build server is not a witchcraft, it facilitates daily work in agile teams and takes continuous delivery processes to a new level. For agencies, this opens up real added value, which, especially in conjunction with a multi-level hosting concept, leads to relaxing deployments that even on Friday afternoons no longer cause headache. A picture-perfect process!
NELE IS HERE!
Nele is the youngest offspring of our groupware Tine 2.0. More precisely Nele is the nickname of the Business Edition 2018.11 and actually it is not so young, but an adult software with many features.
The Hamburger Tafel collects surplus food and distributes it to 27 food distribution points in and around Hamburg. Metaways supports the mostly honorary work with free hosting.
"Hamburg is the most beautiful city in the world," say many locals out of conviction. Of course there are also downsides, but through great honorary commitment, there are attempts at every nook and corner of society to alleviate need.
One example is the Hamburger Tafel, which describes itself as a "social logistician". 400 helpers collect surplus food from numerous retailers and companies and take it to distribution points for the needy.
In the beginning, a card box was sufficient to manage the helpers and donors, but in the meantime the Hamburg Tafel has grown so much that software support was urgently needed. The administration system was provided by our partner SoftwareLoft, who then asked Metaways if we could take over the hosting.
Of course we didn't hesitate and now the administration and the website run on our highly available servers - pro bono. Now we hope that we can also contribute a tiny bit to more people saying: "Hamburg is the most beautiful city in the world!"