Part of the CI/CD Development Series
A UML Deployment Diagram is a static picture that shows the different "nodes" that work together to create an environment. Typically these nodes consist of hardware, software or other key points. It's a high level overview, just enough detail to get the idea across of the layout without getting too lost in the details. These are the three deployment diagrams for our project.
Production
The production deployment is more elaborate than the other two below. Our project has a React front end which means that in addition to images and CSS files, it will also have a largish number of Javascript files. All of these are static and do not need any server side processing. As a result, we don't want them on our ColdFusion server taking up space, memory, bandwidth and other resources when we can use those resources for more efficient processing of ColdFusion files. This allows our server to handle more CF requests since they are not busy processing the static files which do not need the specialized handling. The database is in an RDS environment which also offloads our database handling away from our CF server and allowing it to be a bit more shielded from the Internet.
The servers are in EC2 instances in order to access server scaling, failover and other features. The static files are stored on S3 which is a much cheaper option than spinning up EC2 instances for them. CloudFront also is set up as the CDN for the static files to ensure quick delivery even in different geographic areas.
Testing
Our testing environment here means live testing and previewing. It is the place where interested parties can see the product in its latest iteration, assess and test what features are complete, preview new designs etc. It does not need to be public in that anyone in the world can see it. The accessibility aspect of things is a topic for another post but the options range from obfuscating the address and only distributing that to only allowing certain IP ranges to access the server and so on.
The set up here is relatively simple. There is our database, which at the moment is slated to exist in an AWS RDS instance and a simple AWS LightSail set up. To be very clear, this is not the production database. This is designed to be able to be dropped and recreated often. The reason for LightSail is that his does not necessarily need to be a high powered machine. We're not going to be worried about scaling up or down. We don't need to set up a CDN to optimize delivery. In fact, we probably do NOT want a CDN set up since there is a good chance that this updates frequently. In our case, it will update on nearly, if not every, commit to the repo. The static and ColdFusion files will be served from the same machine since we aren't worried about the number of hits to the server. We are using this to preview features and look, not do real assessment load bearing tests.
Development
The Development Server is the developer's (or whomever's ) local computer. It needs to be able to disposed of and recreated quickly and often. It needs to be easy to set up and also configured to be easy to check code in and out of the repo.
Like in the Testing Environment the static files will be served from the same computer although most of the development and testing of the React files will be using some Webpack / Node.js scripts that auto render the changes being made, making a true "build" an uncommon occurrence. The database will be housed and served on the same machine as well allowing work to continue even when offline.
With the three Deployment Diagrams in place, we can then turn to the Activity D
A UML Deployment Diagram is a static picture that shows the different "nodes" that work together to create an environment. Typically these nodes consist of hardware, software or other key points. It's a high level overview, just enough detail to get the idea across of the layout without getting too lost in the details. These are the three deployment diagrams for our project.
Production
The production deployment is more elaborate than the other two below. Our project has a React front end which means that in addition to images and CSS files, it will also have a largish number of Javascript files. All of these are static and do not need any server side processing. As a result, we don't want them on our ColdFusion server taking up space, memory, bandwidth and other resources when we can use those resources for more efficient processing of ColdFusion files. This allows our server to handle more CF requests since they are not busy processing the static files which do not need the specialized handling. The database is in an RDS environment which also offloads our database handling away from our CF server and allowing it to be a bit more shielded from the Internet.
The servers are in EC2 instances in order to access server scaling, failover and other features. The static files are stored on S3 which is a much cheaper option than spinning up EC2 instances for them. CloudFront also is set up as the CDN for the static files to ensure quick delivery even in different geographic areas.
Testing
Our testing environment here means live testing and previewing. It is the place where interested parties can see the product in its latest iteration, assess and test what features are complete, preview new designs etc. It does not need to be public in that anyone in the world can see it. The accessibility aspect of things is a topic for another post but the options range from obfuscating the address and only distributing that to only allowing certain IP ranges to access the server and so on.
The set up here is relatively simple. There is our database, which at the moment is slated to exist in an AWS RDS instance and a simple AWS LightSail set up. To be very clear, this is not the production database. This is designed to be able to be dropped and recreated often. The reason for LightSail is that his does not necessarily need to be a high powered machine. We're not going to be worried about scaling up or down. We don't need to set up a CDN to optimize delivery. In fact, we probably do NOT want a CDN set up since there is a good chance that this updates frequently. In our case, it will update on nearly, if not every, commit to the repo. The static and ColdFusion files will be served from the same machine since we aren't worried about the number of hits to the server. We are using this to preview features and look, not do real assessment load bearing tests.
Development
The Development Server is the developer's (or whomever's ) local computer. It needs to be able to disposed of and recreated quickly and often. It needs to be easy to set up and also configured to be easy to check code in and out of the repo.
Like in the Testing Environment the static files will be served from the same computer although most of the development and testing of the React files will be using some Webpack / Node.js scripts that auto render the changes being made, making a true "build" an uncommon occurrence. The database will be housed and served on the same machine as well allowing work to continue even when offline.
With the three Deployment Diagrams in place, we can then turn to the Activity D
Slots, Cards and Dice | Sands Casino Hotel
ReplyDeleteSlot machines are easy to find 제왕 카지노 online with the latest versions 1xbet korean of casino games such as slots, table games, poker and 샌즈카지노 table games, as well as video