Rhm2ktmi's List: Application Lifecycle

• I’ve given a continuous delivery workshop a few times with ThoughtWorks Chief Scientist Martin Fowler, who tells an interesting story about continuous integration, from the first software project he ever saw.
• In the early ’90s, a group of experienced, yet jaded, software developers gathered to rethink how to build software. Rather than develop yet another prescriptive process, they focused instead on the practices that had been universally beneficial based on their experience.
• Let’s say you are developing on a local workstation. You make some changes to code, and you do a local build, ensuring that tests have yielded green locally. Once completed, you pull from version control to grab any changes that have occurred since the last time you synchronized yourself with version control. You then do another build, and make sure that your tests remain green.
• Additionally, a couple of new features exist that may or may not make it into the next release of the code base. You decide to use branching in your version control tool to model the problem, an engineering practice known as feature branching.
• Both Professor Plum and Reverend Green, being experienced version control citizens, know that as they each make changes on their particular branch that they should periodically pull from trunk.

3 more annotations...

• So what exactly were we discussing?  Blueprints.  “Blueprint” is certainly an overloaded term and indeed we spent the better part of the first half of the meeting discussing exactly what we meant by it.
•  It was widely agreed that the blueprints should support many app delivery formats: Docker, Linux container, VM, bare metal, and more.
• This means that the same blueprint can be used to provision an app on a developer’s laptop, in a staging environment, in an on-premises virtualized datacenter, and in a public cloud.

1 more annotation...

• How can we achieve top in class development to operations solution lifecycle that slashes operational outages and, at the same time delivers changes at an even faster pace?
  
  During Part 1 I articulated the key DevOps building blocks – people, process and tools. During Part 2 I stated the key challenges that are appartent when trying to implement DevOps type capabilities. In Part 3 I will provide more views on the process principles, the environment reference model and the key environment related characteristics.

• Is DevOps promising too much? If it was as easy as some vendors make it, why are clients struggling with materialising the benefits stipulated? Simply put there are three main reasons: a) Lack of common definition b) Lack of standard implementation approach and c) One size does not fit all.
     

   

    As mentioned earlier DevOps is not a new concept, but the efforts to harmonize several aspects of the entire Development-to-Operation process mark the beginning of a new era. Gartner refers to DevOps as, “…IT service delivery approach rooted in agile philosophy with an emphasis on business outcomes, not business orthodoxy”. (Gartner, Seven Steps to Start Your DevOps Initiative, 16 September 2014, G00270249, Ronni J. Colville [1]).

• Build, Release, Run & Repeat – Enterprises are raving about the agile and perfect fusion between IT Development and IT Operations – to revolutionize the transition, de-risk IT deployments, eliminate the excuse “but-it-works-on-my-system”, and break the silos between developers, testers, release managers, and system operators.
• The Development to Operations (DevOps) promise is Big – to significantly reduce the outages in live caused by changes introduced; according to estimates, 80% of the outages are due to application changes and/ or new application developments.

• • Third, different model, is the movie/game 'studio' model
• Although many companies treat product development as if it were similar to manufacturing, the two are profoundly different.

• Cloudbees’ decision to drop its PaaS, or platform as a service, to focus on continuous integration and delivery is a bit like a car maker deciding to stop building cars to focus on building assembly lines instead. The analogy is imperfect but you get the picture.

• Jay Allen starts by going to the jStart page on GitHub and cloning the Node  MySQL Upload application to his local notebook machine.

• Continuous Delivery (CD) is a software strategy that enables organizations to deliver new features to users as fast and efficiently as possible. The core idea of CD is to create a repeatable, reliable and incrementally improving process for taking software from concept to customer. The goal of Continuous Delivery is to enable a constant flow of changes into production via an automated software production line. The Continuous Delivery pipeline is what makes it all happen.

   

  The pipeline breaks down the software delivery process into stages. Each stage is aimed at verifying the quality of new features from a different angle to validate the new functionality and prevent errors from affecting your users. The pipeline should provide feedback to the team and visibility into the flow of changes to everyone involved in delivering the new feature/s.

   

  There is no such thing as The Standard Pipeline, but a typical CD pipeline will include the following stages: build automation and continuous integration; test automation; and deployment automation.

   
   

• In the new-world of programmable-everything, passwords are certainly not a viable vehicle for strong access control at the automation scale. Configuration files include public ssh keys to securely configure, access and manage the infrastructure, platforms and applications remotely.
• But keys are worthless if exposed improperly. Developers will sometimes inadvertently post their private keys in Git repos, available for anyone to see. Last week, a developer, using simple techniques and code totaling under 80 lines, said he gained access to 5 Amazon EC2 servers in two hours by using Github Search.
• While humans are not perfect, APIs can surely strive to be. While the secure API design guides are aimed at securing the actual API services against security attacks, the design should also consider the data it presents and not respond to sensitive data requests.

1 more annotation...

• In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that
• The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
• The Twelve Factors

1 more annotation...

• Developers today often own both their application code as well as their environment in dev and maybe test as well, while ops owns applications and infrastructure in production, which the top of this image illustrates:

   

   

   

  

   

  On the bottom of this image, conversely, the separation between dev and ops has rotated. This is key.

• Gerrit is a code review system, based on the features that a DVCS gives you.
• Code review systems generally fall into one of two categories, which have advantages and disadvantages
• Pre-commit reviews, in which a diff attached to a review system
• Post-commit reviews, in which the change is committed and then later blessed
• So how does DVCS help here?
• The solution, therefore, is to use branches. If you commit onto a branch, you don’t affect any developers on HEAD(trunk).
• Of course, if you have two concurrent changes, you need two branches.

5 more annotations...

• GWT (pronounced 'gwit') is the official open source project for GWT releases 2.5 and onwards. This site houses links to the documentation, source code repository, issues list and information related to GWT roadmap and release. It is intended for developers interested in contributing to GWT, and for keeping people informed on new and upcoming changes to GWT, GWT related events and other news.

• Vaadin is a Java framework for building modern web applications that look great, perform well and make you and your users happy.

• Atlassian recently announced a new product bundle, Git Essentials, which combines several of its most popular Application Lifecycle Management (ALM) tools and services together with git at the core. Git Essentials can be purchased as a service and run from the public cloud or as an on-premises edition. The suite tightly integrates project management, continuous integration and version control, providing much of the functionality needed for core ALM.
• We believe that application development is, indeed, a vital and valuable part of the industry: our theory is that the majority of cloud spending originates with software developers as the prime movers. Applying the formula 'IT - SaaS = what?' it increasingly seems the case that the 'what?' is custom-written software for ISVs, SaaS and increasingly companies like Nike and Starbucks that are relying on in-house software development for new products such as the Fuelband and mobile payments. Starbucks, for example, is estimated to have pulled in $1bn in sales from its mobile app.
• Atlassian's Git Essentials bundle is going after a major shift in version control happening right now; namely, the move from version control systems like Subversion to the distributed version control system git.
• GitHub has had great success as a public cloud, social-injected git repository service in recent years as well. As our studies consistently show, however, not everyone is choosing public cloud.
• Into this mix of high demand for git in the enterprise comes Atlassian's Git Essentials bundle which tightly couples JIRA, JIRA Agile, Stash (or Bitbucket for the public cloud version), Bamboo and Atlassian's enterprise know-how to create a cloud-based and behind-the-firewall git lattice.
• At present, GitHub's hosted and enterprise edition (behind the firewall) represents a significant competitor for mind and wallet share. While GitHub does not have the full breadth of Git Essentials, buyers will be considering them side-by-side for the primary task of doing git-based version control.
• Perforce Software, CollabNet and WANdisco offer 'enterprise' git.

5 more annotations...

• First, let’s define continuous delivery. Martin Fowler provides a comprehensive definition on his website, but here’s my one sentence version: Continuous delivery is a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users.
• Second, continuous delivery reduces the risk of release and leads to more reliable and resilient systems.
• For me, perhaps the most interesting effect of continuous delivery is the cost reductions it brings about by reducing the amount of time spent on non-value add activities such as integration and deployment.
• Of course this required significant investment.

2 more annotations...