Heroku - 12 Heroku Pipelines and Git and Mergers

Hello everyone and welcome to this heroku tutorial, we have several applications representing different stages of development of development in this lesson long will deepen how to manage the schedules heroku the last blow was in overview there are more in detail on how to work with pipelines how the code of each application is managed we learned that we have several stages for styling development production and also the review apps that are disposable although all these applications share the same base the same source code they are independent while while some are used for testing a production is used as a main happy for the public in sum but now how to manage the code of these applications that are independent and separate this is where guide comes into play as guy you are one of the prerequisites for this course he wouldn't go into too much detail about guide guide allows you to create branches of sections and are copies of code that can be changed independently as you can see in this picture we have three branches one called dave a master is a star game its branches are totally independent of each other depending on which branch you change the code in it will affect one of the applications will affect one of the applicationsif for example you make a coming sure it is in the environment of the mastersit will only affect the application that is in development by the mastersit will only affect production estimates jing will affect staging so let's say you are happy with your progress in the environment and it's time to put everything into production git offers merge so mergethis means that the code merge into one merge does not mean that an application will disappear it just means that the branchingdave and the master or will have the same code so the applications also have the same this correlation between git and pipeline and the way heroescuts offers to avoid you to get confused with infrastructural problems now that we have talked about how to manage the that we have talked about how to manage the code of all applications it is also important to talk about how to move configurations. create applications with add-ons and configuration variables already pre-configured you want to import configurations already made from another application how to do it without having to copy all this manually to each copy of the application in all applications in all languages in the root folder of the project could have a file called to pringy sonnece gie sun is important for heroku because with that one could all configured in the application on this link there is an explanation of how a sound suit works what we see here are complete explanations on the functioning these things naïm description that world website depository logo success etc are mostly descriptions so that we humans can understand that has no impact on the configuration there is for example here the said not used and so on now for the architecture we will your choice really depends mainly on the size of your team the architecture used for a team of The first one I'm going to talk about is the two-layer architecture, which is simple with only ten djing and production if you have a small team with one or two developers this is the one you should use you can organize to choose which person the one of which part of the code and so not to conflict with each other for that you will need the master branch for the production environment you can have your test day jing is just done I have all that with production when everything is functional now three layer architecture when a team has more than two or three people in concert things get a little more chaotic if everyone changes the code in saving since it's just testing it's likely that each person will do their own thing without realizing that they're interfering with the work of others so it's smarter to leave the staging part or the moment when the code is ready and we pass to the test that's why the developers and then will read the revie wapps and when they think that the code is ready to be tested they will be able to suggest to pass it in those of the lines and finally merge it into production if the tests are conclusiveThe four-layer architecture is used when the team has a large number of people entering the system. people entering the teamit is possible that the caudan staging will remain there for several days given the size of the teamit could therefore be that during this time and that can also prepare the deployment of the following code while the code is being tested in saving the deployment often can be prepared in blocks notes as said before these architectures depend on your team so you can see which one fits your team best. That's all for this video but I'll see you soon for the next one!