Marvin Lee Dot Net

What is Continuous Enterprise Development?
The term Enterprise is used for the category of business software that are complex, scalable, distributed, component-based, and mission-critical.
Continuous software development is an umbrella term that describes several aspects of iterative software application development, including continuous integration, continuous delivery, continuous testing and continuous deployment – definition from http://searchsoftwarequality.techtarget.com/definition/Continuous-Software-Development.

• Continuous integration refers specifically to the process of steadily adding new code commits to source code, a concept that has evolved over the years. Originally, a daily build was the standard for continuous integration. Today, the usual rule is for each team member to submit work as soon as it is finished and for a build to be conducted with each significant change. Usually, a certain baseline of automated unit and integration testing is performed to ensure that new code does not break the build. This way developers know as soon as they’re done if their code will meet minimum standards and they can fix problems while the code is still fresh in their minds. An important advantage of continuous integration is that it provides developers with immediate feedback and status updates for the software they are working on.
• Continuous delivery builds on continuous integration and as with continuous integration, each code commit is automatically tested at the time it is added. In addition to the automated unit and integration testing, a continuous delivery system will include functional tests, regression tests and possibly other tests, such as pre-generated acceptance tests. After passing the automated tests, the code changes are sent to a staging environment for deployment.
• Continuous testing adds manual testing to the continuous delivery model. With continuous testing, the test group will constantly test the most up-to-date version of available code. Continuous testing generally adds manual exploratory tests and user acceptance testing. This approach to testing is different from traditional testing because the software under test is expected to change over time, independent of a defined test-release schedule.
• Continuous deployment adds more automation to the process to the software development process. After passing all the automated delivery tests, each code commit is deployed into production as soon as it is available. Because changes are delivered to end-users quickly and without human intervention, continuous deployment can be seen as risky. It requires a high degree of confidence both in the existing application infrastructure and in the development team. Continuous deployment is frequently seen in consumer-facing Web and mobile applications that frequently push updates to their customers as a part of the value that they bring.

The Authors
Andrew Lee Rubinger is an advocate for and speaker on open, testable enterprise Java development, member of the JBoss Core Development Team and Technical Lead of the ShrinkWrap project.
Aslak Knutsen is the project lead of Arquillian, is a Senior SoftwareEngineer at JBoss, by Red Hat. He’s involved in projects such as Arquillian, ShrinkWrap, Weld and Seam 3, and one of the founders of the JBoss Testing initiative.

About The Book
The are various tools explained and used as example for continuous development and testing in this book. Other than JBoss products such as JBoss Forge, JBoss EAP, other important tools such as Maven, Git, Arquillian, ShrinkWrap, OpenShift, Selenium, QUnit and AngularJS are used for the example project.
The book introduces its readers to the importance of proactive error handling and software quality that is the practice in recent software development.
It introduces JUnit and TestNG as test frameworks among the suggested tools as a test plaform for Java EE applications.
The book came along with a great example web application – GeekSeek that is publicly available at http://geekseek.continuousdev.org.
Chapters 5,6, and 7 provides some examples about testing the persistence and business layer while chapter 8 has some good information about REST services. It is crucial to know the stages of REST maturity level used in application, as most developers would misunderstood that their applications are RESTful just because the application is making calls with HTTP methods to some resource URIs.
The book then moved on to making the example application testable on the UI layer and guide readers to have the web app deployed automatically via Jenkins to Openshift.

Chapters
1. Continuity
2. Enabling Technologies
3. Scratch to Production
4. Requirements and the Example Application
5. Java Persistence and Relational Model
6. NoSQL : Data Grids and Graph Databases
7. Business Logic and the Services Layer
8. REST and Adressable Services
9. Security
10. The User Interface
11. Assembly and Deployment
12. Epilogue

Conclusion
This book is very important for modern day web and enterprise application developers to learn to make their application testable at all stages of development. The target reader of this book are experience developers and the examples and content are great to be used as a deployable project right away.
The content of this book can be sampled here, or access online at GitHub or purhased from Amazon via the following link:

Books, Java, Open Source, Review Andrew Lee Rubinger, Aslak Knutsen, CI, Continuous Development

With the advancement of cloud technologies, the options of PaaS (Platform as a Service) for web applications are aplenty. It also helps that there are many available selections to support Java.
Although Red Hat was placed in Gartner ‘Visionaries’ Magic Quadrant, Red Hat’s OpenShift platform is my preferred choice of PaaS at the moment.

OpenShift is a cloud computing platform as a service product from Red Hat. A version for private cloud is named OpenShift Enterprise.

The speed of developing and getting up and running for a product is absolutely crucial for a quick go-to-market advantage, hence any PaaS with the easiest use will have an upper hand over the rest.

For a newer platform like OpenShift, having a book like ‘Getting Started with OpenShift’ is one of the best way to get impatient beginners for a quick run hands-on experience with it. There are many other ways offered such as following the Getting Started – online version or simply the forums, but those are beside the point of this book review.

About The Authors

Steve Poutsy is a Developer Advocate for OpenShift. He has spoken at over 50 conferences and done over 30 workshops including Monktoberfest, MongoNY, JavaOne, FOSS4G, CTIA, AjaxWorld, GeoWeb, Where2.0, and OSCON. Before OpenShift, Steve was a developer evangelist for LinkedIn, deCarta, and ESRI.

Katie Miller is also a OpenShift Developer Advocate. Katie is a polyglot programmer with a penchant for Haskell. The functional programming enthusiast co-founded the Lambda Ladies online community and co-organizes the Brisbane Functional Programming Group. She is passionate about coding, open source, software quality, languages of all kinds, and encouraging more girls and women to pursue careers in technology.

About The Book

The book is meant as ‘A Guide For Impatient Beginners’ but I am glad to say it is not as brief a ‘Getting Started’ guide as any average technical books.

For anyone who doesn’t need any introduction about PaaS concepts, they can dive right in from Chapter 3 as the first couple of  chapters provide conceptual details about PaaS and the basics about cloud computing.

There are 2 important terms in OpenShift, gears and cartridges.

Gears are secure containers for your code. Each gear is allocated CPU, memory, disk, and network bandwidth. A single gear can be used to create an entire web application complete with a private database instance. Multiple gears can be used to create multiple applications or configure your applications to automatically scale in response to web traffic. There are currently three gear types on OpenShift Online: small, medium, and large. Each size provides 1 GB of disk space by default. The large gear has 2 GB of RAM, the medium gear has 1 GB of RAM, and the small and small.highcpu gears have 512 MB of RAM.

Cartridges are plug-ins added to a gear. Cartridges are the plug-ins that house the framework or components that can be used to create and run an application. One or more cartridges run on each gear, and the same cartridge can run on many gears for clustering or scaling. There is quite a list of supported cartridges and OpenShift also supports D-I-Y cartridges, which means most of the popular technologies that you need are already supported by default. Example cartridges are the application servers (Jboss, Tomcat, PHP, Ruby, Node.js, Perl), databases (MongoDB, MySQL, PostgreSQL), and integration tools (Jenkins, cron).

Due to the nature of cloud computing, secure access is important for the application to be accessed or managed. A sub-chapter is dedicated for this and there are sufficient resource in the online guide to get the setup done.

Advanced concepts are also covered in the later chapters of the book, such as storage (it’s shared hosting), websockets, backup options and team collaboration.

Table of Contents

1. Introduction
    What Is the Difference Between IaaS, PaaS, and SaaS?
    The Three Versions of OpenShift
    Choosing the Right Solution for You
    Things to Understand
        Words You Need to Understand
        Technology You Need to Understand
2. Creating Applications
    Preliminary Steps
    Setting Up the Command-Line Tools
    Creating Your First Application
    Autoscaling and Why You Should Use It by Default
    Reasons to Move to the Paid Tier
3. Making Code Modifications
    Cloning Code to Your Local Machine
    Modifying Application Code
    Building and Deploying Your Code
    Action Hook Scripts
    Hot-Deploying Code
4. Adding Application Components
    Database-Related Cartridges
    Nondatabase Cartridges
        Cron
        Continuous Integration
        Metrics and Monitoring
    Finding Cartridges and QuickStarts
        Adding Third-Party Cartridges
5. Environment and Application Management
    SSH Access
        Using SSH to Interact with a Database
        Importing SQL in an SSH Session
    Environment Variables
        Preconfigured Environment Variables
        Custom Environment Variables
        Overriding Preconfigured Environment Variables
    Log Access
    Changing Application Server or Database Settings
        Application Server Configuration Changes
        Database Configuration Changes
    Using Marker Files
6. Library Dependencies
    Where to Declare Dependencies
    Incorporating Your Own Binary Dependencies
    Modifying Your Application to Use the Database
        Code to Connect to the Database
        Code to Close the Database Connection
        Code to Query the Terms for the Insult
        What We Have Gained by Adding a Database
7. Networking
    WebSockets
    SSH Port Forwarding
    Custom URLs
    SSL Certificates
    Talking to Other Services
    Addressable Ports
8. Disk Usage
    Where You Can Write “to Disk”
    Determining How Much Disk Space Is Used
    Copying Files to or from Your Local Machine
    Other Storage Options
9. Backup
    Managing Deployments and Rollbacks
        Manual Deployments
        Keeping and Utilizing Deployment History
    Application Snapshots with RHC
    Backing Up Your Database
        Writing a Cron Script
        Moving Data off the Gear
10. Team Collaboration
    Managing Multiple SSH Keys
    Domain Access for Teams
    Possible Workflows
11. Summary
    What We Covered
    Other Areas to Explore
    Final Words
Appendix A. Basic Linux for Non-Linux Users

You can now download this book in ebook format for FREE or optionally you can purchase it from Amazon.com

Books, Java, Software, Technology Katie Miller, OpenShift, oreilly, PaaS, Red Hat, Steven Pousty

What is Chef?
Chef is a configuration management tool written in Ruby and Erlang. It uses a pure-Ruby, domain-specific language (DSL) for writing system configuration “recipes”. Chef is used to streamline the task of configuring and maintaining a company’s servers, and can integrate with cloud-based platforms such as Rackspace, Amazon EC2, Google Cloud Platform, OpenStack, SoftLayer and Microsoft Azure to automatically provision and configure new machines.
In short, it is the latest tool for system administration to perform configuration tasks on server as well as administrative tasks automation.

About The Authors
Mischa Taylor is a consultant at Chef, a fast-growing Seattle-based startup responsible for creating the Chef platform, which makes it easy to quickly automate development processes and move business processes into the cloud. He has spent his career focusing on building high quality products and increasing engineering productivity within organizations. Mischa is an author, speaker and mentor on software development topics and neuromorphic computing.

Seth Vargo is currently a software engineer and open source advocate at at HashiCorp. Previously, Seth worked at Chef (Opscode), CustomInk, and a few Pittsburgh-based startups. He is passionate about inequality in technology and organizational culture. When he is not writing software or working on open source, Seth enjoys speaking at local user groups and conferences.

So how does Chef works?
1. Chef relies on reusable definitions known as recipes to automate infrastructure tasks. Examples of recipes are instructions for configuring web servers, databases and load balancers.
2. The Chef server stores your recipes as well as other configuration data.
3. The Chef client is installed on each node in your network. A node can be a physical server, a virtual server or a container instance.
4. The Chef client periodically polls the Chef server for the latest recipes and checks to see if the node is in compliance with the policy defined by these recipes. If the node is out of date, the Chef client runs them on the node to bring it up to date.

Chapters
Chapter 1 Configuration Management and Chef
Chapter 2 Configure Your Chef Development Environment
Chapter 3 Ruby and Chef Syntax
Chapter 4 Write Your First Chef Recipe
Chapter 5 Manage Sandbox Environments with Test Kitchen
Chapter 6 Manage Nodes with Chef Client
Chapter 7 Cookbook Authoring and Use
Chapter 8 Attributes
Chapter 9 Manage Multiple Nodes at Once with Chef Server
Chapter 10 Community and the Chef-Client Cookbook
Chapter 11 Chef Zero
Chapter 12 Search
Chapter 13 Data Bags
Chapter 14 Roles
Chapter 15 Environments
Chapter 16 Testing
Chapter 17 Conclusion
Appendix Open Source Chef Server
Appendix Hosted Enterprise Chef

Conclusion
Learning Chef is a book to introduce system administrators and software developers to the automation of systems or infrastructure automation.
The introduction chapters guide the readers to setup the Chef Development Environment, installing necessary tools and the ‘Test Kitchen’ sandbox environment.
Chef itself is written in Ruby, so there is a chapter introducing Ruby for new users.
The book is quite hands-on for readers so you can follow the source code examples that came with the book organized in chapters.
Readers will get to learn how to write recipes, cookbooks, and managing the Chef Server or Nodes.
Although Chef is designed to be a tool for administrative or operational tasks, it has many features including searching for recipes based on IP addresses, shared information for nodes (data bags), roles grouping and environment categorization.
If you are a system administrator, this is definitely a book for you.

Other Resources
Chef Website – http://www.chef.io/
Learn Chef – http://learn.chef.io/
Chef Youtube Channel – http://www.youtube.com/user/getchef
Chef Wiki – http://wiki.opscode.com/display/chef/Home

You can now purchase this title from Amazon:

Books, Review, Technology Chef, Mischa Taylor, Ruby, Seth Vargo