In the production stage, there will be a quick change in the DNS endpoints so that what used to be the environment in the pre-production stage becomes the environment in the production stage. After this completes, you might also have an automated steps in which any or all of the production artifacts are published to a binary repository manager as well. The process time of the DNS change should be measured in milliseconds. That said, it might take time for all of the DNS servers to get updated throughout the Internet, so it might be ISP dependent. This is one of the reasons you might want to have two systems running at once until you can turn off the old system.
Here are some of the file resources used in the production stage:
- Go to your browser and enter
appdemo.yourdomain.com. For example, mine is appdemo.devopsaws.org
- Modify something obvious in your application. For example, I will modify the name of the city from Washington Dulles to San Francisco and the https://github.com/stelligent/honolulu_answers/blob/master/app/views/home/index.html.erb file and the pipeline will get triggered. Once it’s complete, you’ll see the change when going to appdemo.devopsaws.org. The key thing to understand here is that it isn’t just the change in the text of the page on a website, it’s a completely new infrastructure (different EC2 instances, ELB endpoint, security groups, etc.) – everything was generated from code that was committed to a version-control repository and then run from the deployment pipeline – which, itself, is fully described in code and versioned just like the software system it’s building.
Most production releases are long-drawn out efforts in which many engineers work nights or weekends to release the software system. Using this production line concept, the production stage is basically a non event. You click a button and using the automated Route 53 DNS changes, it changes the endpoints so that when users enter the URL, they see the new application with all of its changes.