Software Deployment Principles & Practices

7,936 views
7,493 views

Published on

Software Deployment Principles & Practices

Published in: Education
1 Comment
10 Likes
Statistics
Notes
  • loco hijueputa
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
7,936
On SlideShare
0
From Embeds
0
Number of Embeds
115
Actions
Shares
0
Downloads
0
Comments
1
Likes
10
Embeds 0
No embeds

No notes for slide

Software Deployment Principles & Practices

  1. 1. Software Deployment Principles & Practices
  2. 2. Agenda <ul><li>Objective </li></ul><ul><li>Software Deployment Principles & Practices </li></ul><ul><ul><li>Repeatable Builds </li></ul></ul><ul><ul><li>Consistent Environments </li></ul></ul><ul><ul><li>Autonomous Packages </li></ul></ul><ul><ul><li>Ease to-do/un-do Releases </li></ul></ul>
  3. 3. Objective <ul><li>Basic introduction to Software Deployment Principles & Practices </li></ul>
  4. 4. What is Software Deployment? <ul><li>Software Deployment is the art of deploying software artefacts (CI’s) </li></ul><ul><li>produced as a result of build, on the target environment </li></ul><ul><li>(Development, Staging, Production). </li></ul>
  5. 5. Principles of Software Deployment <ul><li>One can consider 4 basic principles for software deployment, but not </li></ul><ul><li>limited. </li></ul><ul><li>Repeatable Builds </li></ul><ul><li>Consistent Environments </li></ul><ul><li>Autonomous Packages </li></ul><ul><li>Ease to-do/un-do Releases </li></ul>
  6. 6. Repeatable Builds <ul><li>A Typical Application will undergo a simple “build-release-deploy” </li></ul><ul><li>process with a defined build steps. One should have the provision of </li></ul><ul><li>rebuilding the application exactly in the same way as it was built at the </li></ul><ul><li>time of release, to achieve Repeatable builds </li></ul><ul><li>One can Achieve Repeatable Builds, by ensuring </li></ul><ul><li>Versioning of all software artefacts </li></ul><ul><li>Versioning of all tools and its dependencies </li></ul><ul><li>Baselining of all artefacts together </li></ul><ul><li>Automated way of building </li></ul><ul><li>Documented build process </li></ul><ul><li>etc </li></ul>
  7. 7. Consistent Environments? <ul><li>An Environment includes all the components needed to build and run the </li></ul><ul><li>application. </li></ul><ul><li>For a JAVA based application, on the server side the following components </li></ul><ul><li>forms part of environment: </li></ul><ul><li>Operating System (like solaris, HP-UX, AIX) </li></ul><ul><li>System Libraries (like SH, openSSL) </li></ul><ul><li>Services (like Apache, Oracle/Sybase) </li></ul><ul><li>Run time Environments (like JDK, SDK) </li></ul><ul><li>Application Servers (like WPS, Websphere) </li></ul><ul><li>etc </li></ul><ul><li>It is very important to keep all the above components consistent in all </li></ul><ul><li>environments used for the build, release and deployment. </li></ul><ul><li>Example: </li></ul><ul><li>A developer might be doing development on windows based workstations, while the </li></ul><ul><li>deployment has to be carried out on the UNIX based environment. In this case, consistency can </li></ul><ul><li>be maintained at the Tool or Stack Level, by having the same JDK, SDK,app libraries etc. </li></ul>
  8. 8. Consistent Environments?...continued <ul><li>Consistent Environment means in 2 ways: </li></ul><ul><li>All Environments (Development, Staging) should use the same components (System, Software) to maintain consistency with the production environment (sometimes non-realistic, due to parallel dev/testing) </li></ul><ul><li>Consistency with all developer environments (workstation etc) used for development, build and unit test. </li></ul><ul><li>One can achieve a consistent Environment with the following: </li></ul><ul><li>Version control of all components (server, workstation configurations etc) </li></ul><ul><li>Centralizing the storage of the components & its downloads. </li></ul><ul><li>Developing a strategy to run multiple versions of the components </li></ul><ul><li>Automated/Scripted way of deploying components (server, application etc) </li></ul><ul><li>Identifying and Documenting all application dependencies. </li></ul><ul><li>Good Packaging Strategy </li></ul><ul><li>Virtualization (VMWare, Virtual Server) </li></ul><ul><li>Tracking Environment Changes with a good change management tool coupled with a robust process </li></ul>
  9. 9. Autonomous Packages? <ul><li>Autonomous Packages means the deployable package should exist </li></ul><ul><li>independently. The more autonomous the deployable package is the more </li></ul><ul><li>easier to deploy and maintain. </li></ul><ul><li>Why software package autonomous is required? </li></ul><ul><li>Running multiple instances of the packages independently </li></ul><ul><li>All relative paths (configuration, logs etc) is relative to the package </li></ul><ul><li>Application install/un-install, start/stop is independent to each package. </li></ul><ul><li>Each package contains its own dependencies interms of version and libs required. </li></ul><ul><li>: </li></ul><ul><li>: </li></ul>
  10. 10. Easy to-do/un-do Releases? <ul><li>The most important part of the release is to know the environment. </li></ul><ul><li>Doing a software release can be easy as installing a new version of the </li></ul><ul><li>SW package into a single environment or installing multiple packages on </li></ul><ul><li>multiple environments. </li></ul><ul><li>How to ensure SW Releases can be easy to install/un-install/rollback? </li></ul><ul><li>Knowing the Environment </li></ul><ul><li>Understanding the dependencies </li></ul><ul><li>Automated Release Strategy </li></ul><ul><li>Testing </li></ul><ul><li>Backup’s </li></ul><ul><li>Documentation (release steps/notes, dependencies etc) </li></ul><ul><li>: </li></ul><ul><li>: </li></ul>
  11. 11. <ul><li>Thank You </li></ul>

×