## Software Deployment Practices There can be multiple ways of setting up a deployment infra. - Developers initially before starting to build application discuss amongst themselves a release structure and set up a process. #### Jenkins: - Jenkins is a technical butler who just needs to be told on what all things to do for deployment and it takes care of the rest of the work by itself. - The developers create the build (let’s say react build) and then Jenkins “Runs” that build based on the specifications configured by the developers in the config file of the react application. #### Docker: - Docker is a platform which containerizes applications. What it does is that it creates a sort of virtual configured environment for your software and it deploys the application there. - A Docker pod is initially configured by developer who has programmed the application by including the set of dependencies required by the application to run on the server and once everything is provided, Jenkins takes care of making sure it exists on the docker server before deploying the application there. #### Kubernetes: - Kubernetes is gold for saving on infrastructure costs and is truly a blessing. - What it does is that, it takes the Docker Pod and then make cluster which has predefined CPU cores and basically the minimum viable hardware requirements to run the application. - The perk? There can be multiple clusters in a Kubernetes cluster which are dynamically added by Kubernetes if the load tends to increase. - So, let’s say for the initial uses of the application where it is known that there won’t be much traffic, but also there is a possibility that the load increases, if the loads happens to increase for some reason, Kubernetes makes sure that it another cluster gets added automatically with the same set of added hardware declarations and adds up to the previous cluster and improvises the load capacity of the application dynamically, depending on the usage reauirements. *All these steps involve an extensive amount of load testing and different types of tests to ensure it works when it has to, or else it can be said that it should.* ### CI / CD Processes: #### Continuous Integration: In CI, the quality assurance team create multiple test cases which are run through the software development process to keep checking if everything is working fine at all times and that there are no problems or bugs for previously working functions even after new set of features are integrated or any module is updated or changed. It is a process which is extensive in itself involving various testing technique, two of the approaches being: 1. Manual QA Testing: In this process the QA tester manually tests the functions of a software and perform checks to see everything works as specified in the requirements. 2. Automated QA testing: In this process, the QA testing team creates selenium based automated test cases which once programmed, keeps running automatically in specified time durations or based on web-hooks, say when a new build is being merged, so as to test and check the if the application is working as intended. It is a one time effort for any particular application, which then ensures that continuous testing keeps happening to see if every thing works fine or not. #### Continuous Development: In CD, the development works by releasing updates in small batches. In software development, a hierarchy is set which involves multiple branches like developing, staging, production. There can be different structures depending on the size of the project, the team, the process and so on. - For example there is a Development branch which belongs to the developers where they can do all the development an development testing work to ensure the requirements are met and then they further push the code to the staging branch. - In the staging branch, the QA testing team comes into play wherein they perform all the testing and stuff, run test cases to ensure everything works fine, if there happens to be a problem with a certain feature, it is reported and then the bug is handled based on the process followed by the organisation. Then after performing the tests, - The code can be further pushed to a “Pre Production” branch where in once again everything is made sure it’s working fine and as intended. - Then finally the package is pushed to the “Production” branch which is further deployed on the server and it goes live and becomes available to the users. *There are multiple types of checklists which are met before ensuring a certain code goes live on the production server.* Also, there can be more number of branches depending upon the need and practices of the organisation, like some organisations even have a UAT (User Acceptance Testing) Branch wherein the release is made available to the beta registered users to try out the new features early and feedback is collected and further improvements are made before it is made live on the production branch. Again, purely as per the requirement and development process set by the company. ## How release works with the Agile Practices? Let’s take a hands on example. It’s that day of the week again, the Monday and we are starting with the sprint version 2.06. So, a new branch from the Production will be cut stating the new version name for the week, let’s say v2.07 and that will be the playground for the developers for the entire sprint. What developers will do is, they will discuss further internally based on the feature requirements and cut further branches for features. So let’s say there are 4 new features which are planned to be worked on in the current sprint v2.07, the developers will then make 4 different branches for these features (like if features are: 1. Company Onboarding, 2. Screener Report, 3. Candidate Report, 4. Profile View), and then further developers make their own working branch to work on the module locally. Now why this is important is because it is useful when lets say there are two developers working on the same feature, so they can work on their individual branch and then they can further make a Pull Request for merging in the main feature branch. The code is then reviewed by the tech lead or a senior developer and then merged with the feature branch. This ensures that if there are conflicts with the codes of individual developers, it is flagged as a conflict and then gets resolved within this stage only and doesn’t get escalated further. Similarly in this fashion the development takes place and then it goes back in the same structure until it gets merged with the main sprint v2.07 release branch, which is then further deployed to the server if everything works well. There are instances where there are conflicts between codes in the current and previous versions usually this happens in large teams where multiple developers work on the same module, in that case the elected developer than reviews the code and makes changes by either tweaking the code or entirely removing the part which is causing the conflict. ### How are things deployed on the Production Server? The new build first gets set up by Jenkins in the Production server and then before running the entire build, Jenkins wipes the previous build on the Production Server, and then runs the new build in Docker. So, Abhishek, to Abhishek, this is how a deployment process looks like in a software development lifecycle.