![]() Therefore, we chose Vagrant with Ansible provisioning the services like Apache, MySQL, PHP, Solr, etc. A big advantage of Docker was that it ran natively on Linux, but since we needed to support Mac and Windows too, this advantage was not as important to us as Vagrant provisioning a VirtualBox machine that basically works everywhere. Working from the IDEs should have been made possible from the host machineĪt that time, Docker seemed more complex to manage and a bit too young, with lots of changes happening all the time.Since we intended for this to be in use not just by our company but far wider, we needed it to be usable on Linux, Mac, and Windows.As we were building on top of a complex stack, the configuration of the environment needed to be simple.This change is an ongoing process and it takes time, so we wanted a simple tool that is adequate to our needs: booting a dev environment on any developer machine in our company as well as our partners’ and clients’ First of all, we wanted to change our operations, how we do things, but not to dive into a new technology just because it is new.Let me give you a quick review of our reasoning: Looking back, it still feels like we did the right choice despite the fact Docker is even more popular today. With the help of our partner Srdjan, who had more experience with this than us, we chose Vagrant and the service level provisioner Ansible. Docker was already starting to produce a buzz while Vagrant was a bit older but solid. Vagrant or DockerĪ year ago we started to dig into this and we found two options that could help us out: Docker as a container tool and Vagrant as a virtual appliance provisioner. We were wasting time on local installations and configurations, chasing weird bugs on production due to different PHP versions, etc. Some would work natively on Linux or Mac while Windows users had to use a VirtualBox appliance.īut this was still not ideal. That, in return, led to new problems regarding the different OSes and PHP versions the developers use etc. This caused the switch of backend development to the local developer machines. When using Symfony stack and eZ Publish 5, the backend development was mostly done in PHP rather than in eZ legacy templates. This allowed us to manage packages, dependencies, and easier installation on various server environments in a better way. It got even better once legacy eZ Publish extensions were supported by Composer. Using eZ Publish 5 and Symfony stack, we learned the environment specific configuration and dependency management with Composer.This was an important step in consolidating code management and simplifying deployment Several years ago we migrated completely to git (GitHub and Bitbucket). ![]() ![]() We built our own tool for deploying and revoking keys of our team members so it simplifies the management It doesn’t sound like a big deal in 2016 but it is not a trivial thing to do either.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |