Ncerc rlmca202 adm m1 ssm
- 1. RLMCA202 Continuous Delivery Module1 P1 Dr. Sudheer Sankara Marar MCA, MBA, MTech, MA.JMC, PhD HOD-MCA, Nehru College of Engineering and Research Centre
- 2. Foreword.. • If somebody thinks of a good idea, how do we deliver it to users as quickly as possible? • requirements are identified, solutions designed, developed, and tested • these activities joined together and coordinated to make the process most efficient and reliable • enable developers, testers, build and operations personnel to work together effectively
- 3. Introduction • The pattern that is central to this book is the deployment pipeline. • A deployment pipeline is, an automated implementation of your application’s build, deploy, test, and release process. Every organization will have differences in the implementation of their deployment pipelines
- 4. How deployment pipeline works • Every change that is made to an application’s configuration, source code, environment, or data, triggers the creation of a new instance of the pipeline. – first the pipeline create binaries and installers. – Then runs a series of tests on the binaries to prove that they can be released. – Each test that the release candidate passes gives confidence that this particular combination of binary code, configuration information, environment, and data will work. – Once the release candidate passes all the tests, it can be released.
- 5. Some Common Release Antipatterns • The day of a software release tends to be a tense one. Why ? – In many software projects, release is a manually intensive process. – The environments that host the software are often crafted individually, usually by an operations or IS team • be clear about the kinds of process failures and try to avoid them. • Consider a few common antipatterns that prevent a reliable release process
- 6. Some Common Release Antipatterns
- 7. Some Common Release Antipatterns • Antipattern 1: Deploying Software Manually – Instead . . .deployments should tend towards being fully automated. • Antipattern 2: Deploying to a Production-like Environment Only after Development Is Complete – Instead . . . integrate the testing, deployment, and release activities into the development process. • Antipattern 3: Manual Configuration Management of Production Environments – Instead . . . All aspects of production environments, specifically the configuration of any third-party elements, should be applied from version control through an automated process.
- 8. Our goal.. is to deliver software quickly as possible. • Every Change Should Trigger the Feedback Process • The Feedback Must Be Received as Soon as Possible • The Delivery Team Must Receive Feedback and Then Act on It
- 9. Every Change Should Trigger the Feedback Process • A software application can be decomposed into four components: – executable code, – configuration, – host environment, and – data. • If any of them changes, it can lead to a change in the behavior of the application. • Keep them under control and ensure that a change in any one of them is verified.
- 10. The Feedback Must Be Received as Soon as Possible • The key to fast feedback is automation. • If you have manual processes, people take longer time, they introduce errors, and they are not auditable. • People are expensive and valuable, and they should be focused on producing software that delights its users and then delivering those delights as fast as possible— not on boring, errorprone tasks like regression testing, virtual server provisioning, and deployment, which are best done by machines. • Free people to do the interesting work and leave repetition to machines.
- 11. The Delivery Team Must Receive Feedback and Then Act on It • It is essential that everybody involved in the process of delivering software is involved in the feedback process. • The stakeholders include, developers, testers, operations staff, database administrators, infrastructure specialists, and managers.
- 12. What Are the Benefits? • Empowering Teams . • Reducing Errors . • Lowering Stress . • Deployment Flexibility
- 13. Principles of Software Delivery • The ideas behind this book were informed by a large number of projects that the authors have worked on over a period of many years. • As we commenced the activity of synthesizing our thoughts and capturing them in these pages, we noticed that the same principles came up over and over again. We’ve enumerated them here. • These are the things that we can’t sidestep, if we want our delivery process to be effective.
- 14. Create a Repeatable, Reliable Process for Releasing Software • Releasing software should be easy. • Because you have tested every single part of the release process hundreds of times before. • It should be as simple as pressing a button. • The repeatability and reliability derive from two principles: automate almost everything, and keep everything you need to build, deploy, test, and release in version control.
- 15. Automate Almost Everything • There are some things it is impossible to automate. – Exploratory testing relies on experienced testers. – Demonstrations of working software to user community – Approvals for compliance purposes require human intervention. • However, the list of things that cannot be automated is much smaller than many people think. – Acceptance tests can be automated. – Database upgrades and downgrades can be automated. – Network and Firewall configuration can be automated. • You should automate as much as you possibly can.
- 16. Keep Everything in Version Control • Everything you need to build, deploy, test, and release should be kept in some form of versioned storage. • This includes requirement documents, test scripts, automated test cases, network configuration scripts, libraries, documentation, and so on. • It should be possible for a new team member to sit down at a new workstation, check out the project’s revision control repository, and run a single command to build and deploy the application to any accessible environment. • It should also be possible to see which build of your various applications is deployed into each of your environments, and which versions in version control these builds came from.
- 17. If It Hurts, Do It More Frequently, and Bring the Pain Forward • This is the most general principle on our list, and be described as a heuristic. • Integration is often a very painful process. If this is true on your project, integrate every time somebody checks in, and do it from the start of the project. • If testing is a painful process that occurs just before release, don’t do it at the end. Instead, do it continually from the beginning of the project.
- 18. Build Quality In • “Build quality in” was the motto of W. Edwards Deming who was one of the pioneers of the lean movement. • The earlier you catch defects, the cheaper they are to fix. – Continuous integration, Comprehensive automated testing, and Automated deployment, are designed to catch defects as early in the delivery process as possible – The next step is to fix them. A fire alarm is useless if everybody ignores it. • Delivery teams must be disciplined about fixing defects as soon as they are found. – Firstly, testing is not a phase, and certainly not one to begin after the development phase. – Secondly, testing is also not the domain, purely of testers. Everybody on the delivery team is responsible for the quality of the application
- 19. Done Means Released • What does “done” mean? Really, a feature is only done when it is delivering value to users. – For some agile delivery teams, “done” means released into production. • However, it is not always practical to use this as a measure of done. – There is no “80% done.” Things are either done, or they are not. • It is not in the power of one person to get something done. It requires a number of people on a delivery team to work together to get anything done.
- 20. Everybody Is Responsible for the Delivery Process • Within an organization, people work together to help each other. – Ultimately the team succeeds or fails as a team, not as individuals. • However, in many projects the reality is that developers, testers and operations team spend as much time blaming one another at release time, when something goes wrong.! • Break down the barriers between the silos that isolate people in different roles. • Get everybody involved in the delivery process together from the start of a new project, and ensure that they have an opportunity to communicate on a frequent regular basis. • System should also make it possible for people to perform the actions that they need to do their job. • The DevOps movement is focused on the same goal: encouraging greater collaboration between everyone involved in software delivery in order to release valuable software faster and more reliably
- 21. Continuous Improvement • The first release of an application is just the first stage in its life. – All applications evolve, and more releases will follow. • The whole team should regularly gather together and hold a retrospective on the delivery process. – The team should reflect on what has gone well and what has gone badly, and discuss ideas on how to improve things. • Nominate somebody to own each idea and ensure that it is acted upon and they should report back on what happened. This is known as the Deming cycle: plan, do, study, act.
- 23. Configuration Management • Configuration management is a term that is widely used, often as a synonym for version control. • Configuration management refers to the process by which all artifacts relevant to your project, and the relationships between them, are stored, retrieved, uniquely identified, and modified.
- 24. Using Version Control • Version control systems, also known as source control, source code management systems, or revision control systems, are a mechanism for keeping multiple versions of your files, so that when you modify a file you can still access the previous revisions. – UNIX tool called SCCS (Source Code Control System) – RCS, the Revision Control System, – CVS, Concurrent Versions System. • Nowadays there is a wealth of better version control systems, both open source and proprietary, designed for a variety of different environments. – Mercurial, – Git
- 25. Using Version Control • The aim of a version control system is twofold • – it retains, and provides access to, every version of every file that has ever been stored in it. – What constitutes a particular version of your software? – it allows teams that may be distributed across space and time to collaborate. – What was done when, by whom, and for what reason?
- 26. Keep Absolutely Everything in Version Control • Every single artifact related to the creation of your software should be under version control. • Developers should use it; not only for source code, but also for tests, database scripts, build and deployment scripts, documentation, libraries and configuration files, compiler, tools etc • The objective is to have everything that can possibly change at any point in the life of the project stored in a controlled manner.
- 27. Check In Regularly to Trunk • There is a tension as one work with version control. – once you check your changes into version control, they become public, instantly available to everybody else on the team. • A solution to resolve this dilemma is to create a separate branch within the version control system for new functionality. • At some point, when the changes are all satisfactory, they will be eventually merged into the main development branch.
- 28. Use Meaningful Commit Messages • Every version control system has the facility to add a description to your commit. – It is easy to omit these messages, and many people get into the bad habit of doing so. • Purpose & reason to write descriptive commit messages is that, when the build breaks, you know who broke the build and why. – It’s good to use a multiparagraph commit message; in which the first paragraph is a general summary and the following paragraphs add more detail.
- 29. Managing Dependencies • Common external dependencies within your application are – the thirdparty libraries it uses and – the relationships between components or modules under development by other teams • Libraries are typically deployed in the form of binary files, and are not updated very frequently. • Components and modules are typically under active development by other teams and change quite frequently.
- 30. Managing External Libraries • External libraries usually come in binary form, unless you’re using an interpreted language. • There is some debate as to whether or not to version- control these libraries. – For example, Maven, a build tool for Java, allows you to specify the JARs your application depends on and downloads them from repositories on the Internet.This is not always desirable • It makes the version control check-out much smaller. • Its better to keep copies of your external libraries somewhere local
- 31. Managing Components • It’s a good practice to split all applications into components. – It limits regression bugs. – It encourages reuse and – It enables an efficient process on large projects. • Start off with a monolithic build creating binaries or an installer for your entire application in one step, usually running unit tests at the same time. – a monolithic build is usually the most efficient way to build small and medium-size applications.
- 32. Managing Software Configuration • Configuration is one of the three key parts that comprise an application, along with its binaries and its data. • Configuration information can be used to change the behavior of software • Delivery teams need to consider carefully what configuration options should be available, how to manage them • Treat the configuration of your system in the same way you treat your code: Make it subject to proper management and testing.
- 33. Managing Software Configuration • Configuration and Flexibility – Big or small? • Configuration types – Where to inject it? • Managing Application Configuration – How to represent & access the details • Managing Configuration across Applications – Collected in a document management system
- 34. Principles of Managing Application Configuration • Configuration should always be performed by automated processes • Configuration system should be able to provide different values to your application based on its version, and the environment it is being deployed into. • Use clear naming conventions for your configuration options. • Ensure that your configuration information is modular and encapsulated so that changes in one place don’t have knock-on effects for other, apparently unrelated, pieces of configuration. • Use the DRY (don’t repeat yourself) principle; each concept has only one representation • Be minimalist: Keep the configuration information as simple and as focused as possible.
- 35. Managing Your Environments • No application is an island. Every application depends on hardware, software, infrastructure, and external systems in order to work. – the configuration of that environment is as important as the configuration of the application. • Example1:Bus, your application depends on a messaging bus, the bus needs to be configured correctly or the application will not work. • Example2:OS, you may have an application that relies on a large number of file descriptors being available. If the operating system defaults to a lower limit for the number of file descriptors, your application won’t work.
- 36. Managing Your Environments • The kinds of environment configuration information you should be concerned about are: – The various operating systems in your environment, including their versions, patch levels, and configuration settings – The additional software packages that need to be installed on each environment to support your application, including their versions and configuration – The networking topology required for your application to work – Any external services that your application depends upon, including their versions and configuration
- 37. Introduction to Continuous integration • In many software projects, for long periods of time during the development process the application is not in working state. • Nobody is interested in trying to run the whole application until it is finished. • Continuous integration requires that every time somebody commits any change, the entire application is built and a comprehensive set of automated tests is run against it.
- 38. CI - origin • if the build or test process fails, the development team stops whatever they are doing and fixes • the problem immediately. The goal of continuous integration is that the software is in a working state all the time. • Continuous integration was first written about in Kent Beck’s book Extreme Programming Explained • the idea behind continuous integration was that, if regular integration of your codebase is good, why not do it all the time?
- 39. CI - Purpose • The teams that use continuous integration effectively are – able to deliver software much faster, and with fewer bugs, – Bugs (if exist) are caught earlier and are cheaper to fix, providing significant cost and time savings. • It’s considered it an essential practice for professional teams, perhaps as important as using version control.
- 40. Implementing Continuous Integration • The practice of continuous integration relies on certain prerequisites • What You Need Before You Start – Version Control : Everything in your project must be checked in to a single version control repository – An Automated Build : You must be able to start your build from the command line. – Agreement of the Team : Continuous integration is a practice, not a tool. It requires a degree of commitment and discipline from your team. • A Basic Continuous Integration System – CI tools are extremely simple to install and get running. – next step is for everybody to start using the CI server.
- 41. Prerequisites for Continuous Integration • Continuous integration won’t fix your build process on its own. Following practices will need to be in place before you start. • Check In Regularly : checking your code in trunk, at least a couple of times a day. • Create a Comprehensive Automated Test Suite : Automated testing (CI build focuses all unit tests, component tests, and acceptance tests) provide confidence that your application is actually working. • Keep the Build and Test Process Short :say two stages. – One should compile the software, run your suite of unit tests and create a deployable binary. This stage is called the commit stage. – The second stage should take the binaries from the first stage and run the acceptance tests, integration tests, and performance tests • Managing Your Development Workspace – Developers should always work from a known good starting point – a good application architecture allows the application to be run without much trouble on a development machine
- 42. Using Continuous Integration Software • The most basic functionality of continuous integration software is to poll your version control system to see if any commits have occurred and, if so, check out the latest ersion of the software, run your build script to compile the software, run the tests, and then notify you of the results.
- 43. Basic Operation • At heart, continuous integration server software has two components. • FIRST, a long-running process which can execute a simple workflow at regular intervals. • SECOND, provides a view of the results of the processes that have been run, notifies you of the success or failure , and provides access to test reports.
- 44. Bells and Whistles • You can use your CI package’s workflow capabilities to do lots of other things beyond the basic functionality. • For example, you can get the status of the most recent build sent to an external device. • Some creative people use red and green lava lamps to show the status of the last build, or a CI system that sent the status to an external component • Projects use gadgets like these are a great way to allow everyone to see the status of the build at a glance. • Visibility is the most important benefits of a CI server.
- 45. Essential Practices • We have always described about the automation of building and deployment. However, that automation exists within an environment of human processes. • CI is a practice, not a tool, and it depends upon discipline to make it effective. Keeping a continuous integration system operating, requires a significant degree of discipline from the development team as a whole.
- 47. Essential Practices • Don’t Check In on a Broken Build – Never check in on a broken build. If the build breaks, the developers responsible are waiting to fix it. • Always Run All Commit Tests Locally before Committing – CI servers Pulse, TeamCity, and ElectricCommander offer this feature. They offer a distributed version control system which lets you store commits locally without pushing them to the central server. • Wait for Commit Tests to Pass before Moving On – Build breakages are a normal and expected part of the process. Find errors and eliminate them as quickly as possible, without expecting perfection and zero errors.
- 48. • Never Go Home on a Broken Build – check in regularly and early enough to avail time to deal with problems as they occur. • Be Prepared to Revert to Previous Revision – If we can’t fix the problem quickly, we should revert to the previous change- set held in revision control and remedy the problem in our local environment. • Time-Box Fixing before Reverting – Establish a team rule: When the build breaks on check-in, try to fix it for ten minutes. If, after ten minutes, you aren’t finished with the solution, revert to the previous version from your version control system. • Don’t Comment Out Failing Tests – At times, developers comment out failing tests in order to get their changes checked in. This impulse is understandable, but wrong. • Take Responsibility for All Breakages That Result from Your Changes
- 49. Distributed Teams • Using continuous integration with distributed teams is, in terms of process and technology, largely the same as in any other environment. • Probably, the team is not sitting together in the same room—perhaps they are even working in different time zones – The Impact on Process – Technical Issues – Alternative Approaches • For scattered aspects, move to a distributed version control system such as Git or Mercurial
- 50. Distributed Version Control Systems • The rise of distributed version control systems (DVCSs) is revolutionizing the way teams cooperate. • Tools like Git and Mercurial make it incredibly easy to pull patches back and forth between developers and teams and to branch and merge work streams. • DVCSs are a great advance and provide powerful tools for collaboration.
- 51. Implementing a Testing Strategy • We’ll discuss some key strategies for automating tests in commonly occurring situations and describe practices that support and enable automated testing. • Testing is a cross-functional activity that involves the whole team, and should be done continuously from the beginning of the project. • The design of a testing strategy is primarily a process of identifying and prioritizing project risks and deciding the actions to lessen them
- 52. Implementing a Testing Strategy A good testing strategy has many positive effects. • Establishes confidence that the software is working as it should – Fewer bugs, reduced support costs, and improved reputation. • Encourages good development practices. • A comprehensive automated test suite provides the most up-to-date form of application documentation
- 53. Types of Tests • Brian Marick came up with a model listing the various types of tests that you should have in place to ensure the delivery of a high-quality application. • He categorized tests according to – whether they are businessfacing or technology-facing, and – whether they support the development process or are used to critique the project
- 54. Types of Tests
- 55. Business-Facing Tests That Support the Development Process • The tests in this quadrant are more commonly known as functional or acceptance tests. – Acceptance testing ensures that the acceptance criteria for a story are met. – Acceptance tests should be written, and ideally automated, before development starts on a story. • Acceptance tests, can test all kinds of attributes of the system being built, including functionality, capacity, usability, security & availability – Write the main happy path test, first.. – When you have time to write and automate further tests, choose between alternate happy paths and sad paths.
- 56. Technology-Facing Tests That Support the Development Process These automated tests are written and maintained exclusively by developers. There are three kinds of tests that fall into this • Unit tests: test a particular piece of the code in isolation • Component tests: test larger clusters of functionality, performing more I/O, talking to databases, the filesystem, or other systems. (Sometimes, component tests are known as integration tests) • Deployment tests: are performed whenever you deploy your application. They check that your application is correctly installed, correctly configured, able to contact any services it requires, and is responding perfectly.
- 57. Business-Facing Tests That Critique the Project • These manual tests verify that the application will in fact deliver to the users the value they are expecting. • Inevitably, when users try an application in real life, they discover that there is some room for improvement – Showcases: Agile teams perform showcases to users at the end of every iteration to demonstrate the new functionality that they have delivered. – Exploratory testing: is a creative process that will also lead to the creation of new sets of automated tests, and contribute into the new requirements for the application. – Usability testing: is done to discover how easy it is for users to accomplish their goals with your software.
- 58. Technology-Facing Tests That Critique the Project • Acceptance testing comes in two categories: functional tests and nonfunctional tests. • Nonfunctional tests, checks whether all the qualities of a system other than its functionality, such as capacity, availability, security, are met.. • For complex or mission-critical projects, you should allocate project time to researching and implementing nonfunctional testing from the start of your project.
- 59. Test Doubles • A key part of automated testing involves replacing part of a system at run time with a simulated version. • Such simulations are often known as mocks, stubs, dummies etc – Dummy objects are passed around but never actually used. – Fake objects actually have working implementations, but usually take some shortcut that makes them not suitable for production. – Stubs provide canned answers to the calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. – Spies are stubs that also record some information based on how they were called. – Mocks are preprogrammed with expectations that form a specification of the calls they are expected to receive..
- 60. Real-Life Situations and Strategies Here are some typical scenarios faced by teams who have decided to automate their tests. • New Projects : the cost of change is low and, by establishing some relatively simple ground rules and creating some relatively simple test infrastructure, you can give a great start to your process of continuous integration. – start writing automated acceptance tests from the very beginning • Midproject : Although it’s always pleasant to be starting a project from scratch, at times you may be put on a large, resource-starved team developing a rapidly changing codebase, under pressure to deliver. – begin with the most common, important, and high-value use cases of the application, in conversations with your customer to clearly identify where the real business value lies
- 61. Real-Life Situations and Strategies • Legacy Systems: defined (controversial) as systems that do not have automated tests. – Along with this simple definition comes a simple rule of thumb: Test the code that you change – Once these smoke tests (it determines whether the deployed build is stable or not.) are in place, you can begin development on stories. • Integration Testing: if the application is conversing with a variety of external systems or if it consists of a series of modules with complex interactions between them, then integration tests become very important. – Integration testing ensure that each independent part of the application works correctly with the services it depends on. – Integrating with external services is complex and requires time and planning
- 62. Process • The production of acceptance tests can be an expensive and laborious task, if communication between the team members isn’t effective. • The results of this process might be sent to the customer for approval, following which the tests are implemented. • Get customers, analysts, and testers in a room together and come up with the highest-priority scenarios to test. – TWO approaches to deal it with
- 63. Process • Approaches – Simple approach: Tools like Cucumber, JBehave, Concordion, and Twist aids to write acceptance criteria (in natural language) in a text editor and then write executable code – Another approach: is to use a domain-specific language (DSL) for testing. • Close collaboration between developers and testers throughout the development of a story is essential to a smooth path to the release. Whenever developers finish some functionality, they should call over the testers to review it.
- 64. Tree & Swing paradigm
- 65. Managing Defect Backlogs • Ideally, bugs should never be introduced into your application in the first place, if you are practicing continuous integration and have a comprehensive set of automated tests • However, Exploratory testing, Showcases, and Users will inevitably discover some bugs in your system. These bugs will typically end up in a defect backlog – One approach to handle is whenever a bug is found, it is immediately fixed. The team be structured in such a way that testers can find bugs early, and developers can fix them straight away. – Another approach is to treat defects the same way as features, so it is up to the customer to prioritize the relative importance of a particular bug against some feature.
- 66. Thank You • End of M#1 © dr. sudheer s marar DEPARTMENT OF MCA NEHRU COLLEGE OF ENGINEERING AND RRESEARCH CENTRE