Groovy & Grails - From Scratch to Production

Grails – from scratch to production

How we build successful application

Tal MaayaniNovember 2013

Agenda• About the lecturer • Choosing the technology: Grails vs…• Common pitfalls• Development methodologies• Continuous Integration• Q&A

Choose the right technology• Project type: self service web application with a rich back office• Project roadmap: workflow, many integrations with external vendors, analytic,

payments• Timeline: start development within a short period, full power development

within 3 months, production within 6 months• Budget• Available in-house skillset

Requires fast web development framework like Spring ,Play, Rails, Grails, Django

Comparing between alternativesFeature Grails RailsLanguage Groovy - JVM based Ruby - Interpreter based

Approach Domain oriented Database oriented

Thread support Native Poor

Hardware requirements Requires more memory, and strong CPU

mediocre memory and CPU

Learning Curve Fast for a java developerslonger than Grails since Rails operates

in Database model

Maturity Less Mature (Founded at 2008) More mature (Founded at 2004)Scalability Offer good scalability Lack scalabilityLibraries Offers all java based libraries No java libraries

Why we chose Grails?• Build on known technologies that we already used

• Spring, Hibernate, Tomcat, Quartz• Fast development

• Scaffolding , Smart reloading, Hundreds of plugins (~1000), groovy• MVC web application

• Domain, GSP, Controller

Common Grails pitfalls• Writes java in groovy Use outsource grails experts• Difficult debugging (comparing to java) More logging• Maintaining data model Liquibase• Groovy dynamic nature Test everything• Some plugins are unstable Smart use of plugins• Highly hardware demands Use strong machines

Groovy EcosystemGrails

RAD PlatformGradle

Build framework

CodenarcStatic code

Analysis

GaelycToolkit for GAE

GriffonSwing UI

EasyBBDD

SpokeJunit

GparsMuti-threading

GContractDesign by contract

And many more …

Development processHighlights

• Holistic thinking: • production deployment, performance, testing, interfaces

• Lean development • Development of only what is required

• Test on production like environment • System test as soon as possible• Learn from mistakes

Grails PluginsRecommendations

• Do not blind use plugins• Plugins dependencies and footprint considerations• Performance consideration (startup overhead)• Write your own set of plugins (configuration, health check, authentication,

taglibs)• Maintain up to date plugin

• JS wrapper plugins (Jquery, bootstrap) –• Not always up to date and maintained • sometimes it is preferable to copy the js library instead of using the plugin

Plugins that we used• In house development• Spring web flow – state machine for managing flows• aws – enable use of amazon via grails service• Cache, zipped resources• Less-css• Spring security• Quartz• Yammer metrics

AWS Configuration Loader Plugin• Enable the use of external configuration file for per environment

settings• Server name, performance tuning, etc.

• Receive configuration file • Local file – for development• S3 URL – when running on amazon. Use access and secret keys.

• How it works? • Copy the external configuration file locally and merge config.groovy

Liquibase Plugin• Use when

• You are using relational DB on production• Have a frequent schema changes

• Major functionality• Keep record of every db schema change, use DSL to record these

changes• Enforce object model & DB match (using MD5)• Allows to have business logic (in groovy) to support migrations

Liquibase Plugin – cont.• Drawbacks (for 1.3.6 and below)

• Maintenance • Do not use per environment configuration in datasource.groovy

• Extension• Allow running any sql script in change set

For example: Quartz schema

Health Check• Get report for instance health

• Access to various data sources (MySQL, Mongo, Oracle)• Access to other components

• Triggered from monitoring system • Report generated ad hoc

• Implemented in grails plugin• Building block per access point

Working with AmazonEC2 vs. Elastic Beanstalk

Capability EC2 BeanstalkConfiguration Management

Flexible, can run scripts on instance build, deployments. Can use CM like chef or puppet

Use prebuild AM with given configuration. Can use limited Yml script for customization

Monitoring, Load Balancing, Auto scaling

Need to configure Automatically defined

Application management

- Manage logs, environment configuration, versions, externalize configuration properties

Stopping environment

Environment can be stopped Environment cannot be stopped

Deployment Custom script AWS API call

Continuous IntegrationUsing Amazon

Dev. commits Build server run unit tests

Build server deploy war to dev integration environment Build server deploy war to amazon QA environment

Build server triggered Selenium to run subsystem test against QA

War is ready (PSP)

KPI Measurements• Define a set of goals that measures success

• Total # of users, abandonment rate, conversion rate• Define measurements tools• Systematically and periodically measure • Learn from the results