Designing a simple Deployment for Web Projects
•Download as PPTX, PDF•
0 likes•83 views
Having a consistent process to deploy and test code can save you a lot of time, money, and headaches in the long run. This slide is for people who want to understand how to design a simple deployment workflow for their web projects. It is also a good introduction to devops and continuous integration. http://www.bensangeorge.com/2017/01/29/design-a-simple-deployment-for-web-projects/
Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Designing a simple Deployment for Web Projects
- 1. Deployment Environments • Setup to perform a unique function • Each environment is a server • As you move through environments, your code should become more stable • Process of deploying to servers = Deployment Workflow
- 3. Development Environment • Developers use this area as a sandbox • Used to collaborate with developers • Unstable • Deploy code via FTP • Low resource machine
- 4. Staging Environment • Stable area for stakeholders to review and verify that the solution works • Run stress tests + functional tests • More stable than the development environment • Deploy code via some version control (Git) • High resource machine (mimic LIVE)
- 5. Production Environment • The finish line for your code • Should only be deployed once stakeholders have approved it • Deploy code via Git
- 6. Deployment Workflow 1 Development Staging Production * Used as sandbox * Push via FTP * Stakeholder approved * Push via Git * Stakeholder review * Push via Git
- 7. Deployment Workflow 2 Development Staging Production * Used as sandbox * Push via FTP * Stakeholder review * Push via Git * Stakeholder approved * Push via Git
Editor's Notes
- First, let’s talk some basic concepts about environments. [1] Each environment is setup to perform a very unique function in the software development process. [2] Now, for our design, we will have a server for each of our environments. [3] When you group together multiple servers for the purpose of deploying code, you have a deployment workflow. [4] As you move through each environment towards the live server, your code should become increasingly more stable.
- Turning back to our design, [1] let’s call the first one our development environment, [2] the second one our staging environment and the [3] third environment our production (or live) environment. Let’s talk about these servers in more detail.
- The development environment is an area developers are constantly pushing to in order to test their particular feature that they are building. [1] Devs use this environment as a sandbox. [2] They may also be doing work on this server that is in collaboration with other developers. [3] You have to treat this environment as very unstable. Server outages in this environment shouldn’t . [4] Developers should usually deploy code in this environment via FTP or a “manual” method like this. I will cover the details of how exactly to build this out in other videos. [5] The specs for this development server can be minimal. You can get away with having 1 processor and 4GB of memory if you are only hosting one project at a time. You can also place all of your main services in the same server as well. By services, I mean your database server, your web server, your caching engine, etc.
- Let’s talk about the staging server next. The purpose of a staging environment is twofold: [1] Provide a stable area for developers to push changes that stakeholders can approve. These stakeholders can be members of the project management or business requirements team that requested the changes in the first place. [2] Run tests against your new code. These tests can look at your new code’s functionality. You can also run regression tests to make sure that your new codebase does not severely affect the code that you have in place. It’s important to make sure that we mimic the live environment and how your project will respond when it gets to the live server. Because of this, you want to make sure the physical resources on your staging server is beefier than your development environment and reflects the production environment.
- [1] The production server is the finish line for your code. Before you think about deploying to production, you should have received stakeholder approval to get your changeset out. In terms of deploying code to the staging and production environments, [3] I would recommend using a managed-code solution with Git or another version control system. This minimizes the number of changes that affect your servers at any point in time.
- So let’s bring this all together in a simple example. [1] So a developer wants to start working on a new feature or an issue on the development server. [2] Once you feel like you have a good solution, you will have to push it to the QA server for it to be approved by stakeholders. [3] Once your change has been approved, you finally deploy this to the production server. Remember that both QA and production environments need Git to push your changes.
- Now what I just shared with you was just to get a simple deployment workflow running. For many projects, you would be fine with this setup but depending on the amount of traffic your web project it gets, you will outgrow this setup very fast. For example, you may want to have a dedicated server for your databases and caching engines. Also you can load-balance certain parts of your live infrastructure like your web servers to handle more load to your live site. In the end, you will see many different flavors of this but the biggest takeaway that you need to understand is that each environment serves a unique and specific purpose.