You are on page 1of 9

DEVOPS-INFRASTRUCTURE

EXPLAINED

Automatically fetching all the artifacts from version control. Automatically Integrating . Deploying the Validated build from staging to production .and validating the new system..tests.Deploying and Validating the code in a staging Environment.SIX RECOMMENDED PRACTICES – INFRA SETUP • To support the practices the following three main processes needs to be followed-Thumb rule. .including the code. automated as far as possible.scripts. A. C.etc.metadata. B.

. For eg: it may be sufficient to have only two instances of the application server instead of twenty .with a cheaper load balancer from the same vendor-all that may be necessary to ensure that new functionality is validated in a load-balanced environment.the company should build a staging environment.media content lives on separate servers. There .for example . There . preceded by a load balancer.the Program teams can continuously validate their software in preparation for deployment. and more. which has the same or similar hardware and supporting software systems as production. the must larger scale production database is clustered .SIX RECOMMENDED PRACTICES – INFRA SETUP #1.there are a variety of ways to achieve that functionally equivalence without such investment. Mostly it is not economically viable(hundreds or thousands of servers). “The deployment will fail and debugging and resolution will take an unpredictable amount of time” . After hand off from development to production . Build and Maintain a Production –Equivalent Staging Environment Explanation: The need of this environment is driven by the fact most of development environments are typically quite different from production.the application server is behind the firewall.Instead .

Explanation: • • The above is a solution to a different root cause. which is routine at scale) do not closely match production. Maintain Development and Test Environments to better Match Production.SIX RECOMMENDED PRACTICES – INFRA SETUP #2.configurations.etc back to the other environments. Faithfully propagating and persisting the new development initiated configurations/environment changes to production during each deployment. such as component or supporting system upgrades. software configurations can typically be affordably replicated across all environments.changes in system metadata. In both cases. configuration changes need to be captured in version control. which itself can also be mitigated. that is that the various and multiple development environments required for development( especially distributed development. This can be accomplished by: Propagating all changes in production.while it may not be practical to have a separate load balancer for every developer. For example . and all the new actions required to enable the deployment flow should be documented in scripts and automated wherever possible . Part of the reason for this is a cost. encumbered by a lack of understanding of the true cost of delay of deployment. which may be driven by practical economics.

Explanation: 3a): Deploy to staging every sprint.channels. It is under the authority of the release management. the real benefits in shortening lead time from actually deploying to production more frequently. 2. In that way.production.security or other such requirements 3. And while continuous deployment readiness is critical to establishing a reliable software delivery process. This also helps eliminate long –lived production support branches and consequential extra effort required to merge and synchronize changes across all the instances. It is not possible to objectively understand the true state of any increment unless it is truly deployment ready. one suggestion is a simple rule: do all fortnightly System Demos (EXPLANINED IN LAST SLIDE)from the staging environment.SIX RECOMMENDED PRACTICES – INFRA SETUP #3.regulatory. deployability becomes part of definition of done for every story. and any external market timing considerations. Integrity of feature set. Which includes 1.Potential Impact to the customers. deploy to production Frequently. . resulting in potentially deployable software every sprint. To better assure this. Fully automated Deployment model needs to established. we must also consider release governance before we allow an “automatic push “ to production.Evaluation of Quality. Deploy to staging every sprint. 3b): Deploy to Production Frequently.

. Put Everything Under Version Control.SIX RECOMMENDED PRACTICES – INFRA SETUP #4. • New code and its required data • Libraries • External assemblies • Configuration files or databases • Applications or Database servers • Test data • Test scenario Etc all these realistically be updated or modified-needs to be under Version Control. • All deployable artifacts • Metadata • Other supporting configuration items. Explanation: In order to able to reliably deploy to production.

SIX RECOMMENDED PRACTICES – INFRA SETUP #5. These include preparing the operating environment. This can be achieved by using virtualization. . To achieve this Environment setup process needs to be fully automated.. manually intensive routines that are required to build the actual runtime environments. configuring the artifacts. Explanation: Many Deployment problems arise from the error prone. applications and data. etc. USING IaaS …Infrastructure as service. Start Creating the Ability to Automatically Build Environments.

• Building the Code • Creating the test environments. Staging. and Production) environment. i. • Deploying and Validating the verified code and associated systems • Utilities in the Target ( Development. . Explanation: Lastly. it should be obvious that the actual deployment process itself requires automation.SIX RECOMMENDED PRACTICES – INFRA SETUP #6. • Executing the Automated tests.e. Start Automating the Actual Deployment process.

customers and customer resources. Share demo responsibilities amongst the product managers and product owners who have the new features to demonstrate.SYSTEM DEMO PROCESS AND AGENDA • • • • • • BRIEFLY REVIEW THE BUISNESS CONTEXT AND THE GOALS FOR THE TEAM’S SPRINTS(5-10 Mints) BREIFLY DESCRIBE EACH NEW FEATURE OR CAPABILITY THAT WILL BE DEMONSTRATED(5 Mints) DEMONSTRATE EACH NEW FEATURE AND END-TO-END USE CASE(5 MINS). Shared Resources. OPEN THE FORUM FOR QUESTIONS AND COMMENTS. who are for responsible for staging the demo on the QA or demo environment.biweekly involvement of the stakeholders. IDENTIFY ANY CURRENT RISKS AND IMPEDIMENTS THAT MAY HAVE EMERGED FROM THE DEMO AND PROGRESS OVER THE LAST SPRINT. This is critical to keep the continous. Minimize the Power Point slides. testing code of completed features and stories. Executive Sponsors. Business Owners. GUIDELINES FOR SUCCUSSFUL SYSTEM DEMO • • • • Time-box the demo to one hour. who are typically responsible for running the demo. WRAP UP BY SUMMARIZING THE PROGRESS. Discuss the Impact of the current increment on the system NFR( NON-FUNCTIONALREQUIREMENT). ATTENDEES • • • • Product Managers and Product Owners. deployment Operations and other Development Participants. One or more members of the System Team. demonstrate only working.FEEDBACK AND ACTION ITEMS . . The System Architect. It also illustrates team professionalism and solution readiness.