4/1/2023 0 Comments Teamcity alternatives![]() ![]() It's modern, robust and unlike most of the light-weight alternatives, it's transparent. Namely, we need something to manage our CI/CD pipelines. If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. ![]() We must also give proper consideration to monitoring and logging hoovering at this point. ![]() That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. I should probably digress here for a moment and explain why. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is )). Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ). Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |