Jez Humble on Continuous Delivery and DevOps

In the last year, during the period i have been in France, attending Université du SI, one of the best conferences i've participate in whole life (sponsored by OCTO Technology), i had the privilege of being invited to participate in a very interesting course with Jez Humble,  about Continuous Delivery for DevOps.
After the course, i could make an interview for InfoQ Brazil, but for obvious reasons we translated it to Brazilian Portuguese. And now, here goes the original version. Enjoy!

You wrote a best seller, called Continuous Delivery, What is it all about?

It's about all the stuff that is normally considered somewhat peripheral to software development - configuration, build and deployment management, automated testing, continuous integration, infrastructure and database management. However the discovery that many of us made while working on large agile projects was that this stuff is essential if you want to be able to reliably, repeatably release high quality software.

Actually many of the ideas in the book aren't new. It's really a call to arms to focus on the engineering practices that were always at the heart of agile methodologies, but that somehow got sidelined in many places over the last ten years. Of course several tools like Puppet, Chef, Git and DbDeploy have emerged that didn't exist ten years ago that make much of this stuff much more tractable.

It turns out that the engineering practices - particularly automation of build, test, deployment, and database and infrastructure management - and collaboration between development, testing and operations - are really essential to be able to get high quality software delivered fast. And that, in turn, is central to the ability of organizations to innovate and get new features out of the door quickly and reliably.

What practices do you think are more important?

For developers, you need to start with continuous integration. That doesn't mean installing a CI server and pointing it at your feature branches - it means making sure everyone merges regularly into mainline (and yes, that applies to Git too). In order for CI to be useful, you need automated tests, in particular at the unit and acceptance level. Having a comprehensive, maintainable set of unit tests is almost impossible without doing TDD. Creating maintainable acceptance tests requires close collaboration between developers and testers. Finally, you need to validate every build to ensure it's production ready, which means having the ability to spin up production-like testing environments on demand and run realistic loads against your system. This requires automated provisioning of environments and infrastructure, and automated deployment of your system, including any database changes. All of this needs to be implemented within the context of the deployment pipeline.

These kinds of changes need to be made incrementally, by finding out where the constraints are in your delivery process and removing them one by one. That in turn requires close collaboration between developers, testers and the operations department. More on that later.

We have seen, that some people make some confusion about the term Continuous Delivery, can you explain to us, what's the difference between Continuous Delivery and Continuous Deployment?

Continuous delivery means you can release on demand. I should be able to release the latest good build at the press of a button without having to worry that it's going to break. But when you release is a business decision. Continuous deployment means you actually go ahead and release every good build. Obviously that only really applies in the context of websites or software-as-a-service. But if you can't actually do continuous deployment and release every good build for some reason - say you're working on a user-installed product - you should at the very least be putting every good build into a production-like environment and running realistic acceptance and performance tests against it so that there are no surprises when you come to release it. You can do that on embedded systems, products, pretty much anything that involves software.

Organizations that could in principle do continuous deployment really should aim to. One of the key benefits is organizational. Continuous deployment makes developers care much more about the quality and reliability of what they're doing because if they can push a button to make their changes go live, it connects them with what's going on in production. And it makes the business focus much less on stuffing features into a release when they know they can create some small feature, have it in production in a couple of days' time, and get real feedback on whether it's valuable and whether more effort should be put into it. It is a complete paradigm shift in the way organizations work and they become much more responsive to their customers. Eric Ries writes more about this in his forthcoming book, The Lean Startup

Can you explain to us, the term DevOps, and what that means?

DevOps is kind of an anti-movement, by which I mean it has resisted attempts to pin it down. But fundamentally it's about putting a strong focus on collaboration between everybody involved in software delivery - in particular, developers, testers and operations - and sharing knowledge and techniques between them. Infrastructure-as-code is one example of knowledge sharing - the application of agile techniques such as refactoring and test-driven development to evolving your infrastructure. DevOps is essential to achieve continuous delivery.

Part of the reason people in the movement have resisted (for example) creating a manifesto is to prevent vendors (in particular tool vendors) from appropriating it and trying to own it. Often people are guilty of reaching for tools (even within the movement - myself included) when actually it's the attitude and mindset that makes you successful. That's not to say the tools aren't important - they are. Tools that can't be managed in an automated fashion through an API are especially unpopular within the community.

How do you implement DevOps?

One really good way to start is to get representatives from every part of the organization involved in delivery - development, testing, infrastructure, operations, product management - to get together regularly and have retrospectives to reflect on how to incrementally improve things. In many organizations, you never see people from every department in a meeting together. It just doesn't happen.

Another way to get going is for everyone involved in delivering software celebrate successful releases together. Really implementing DevOps is about change that works up from the people on the ground - it's hard to mandate it. That's one of the reasons senior management has a hard time with it. But it's also the secret sauce - incremental, bottom-up change is usually the most effective and long-lasting.

What skills related to Infrastructure a modern developer should have? And why it is important? Does it make sense, for companies that are not in the cloud?

I think the key element is that infrastructure provisioning and management has to be automated. It should be possible to plug a new server (or workstation) in - power and network - and bring it into the correct state, configure it, and deploy to it in a fully automated fashion. You can do that whether or not you're in the cloud. In fact ThoughtWorks recently did some consulting to automate hardware provisioning and management for one of the cloud vendors. Under the hood, "the cloud" of course runs on real hardware and the same principles apply.


For great companies, that has already an Operation Department, what a developer can do to decrease this gap between devs and ops?

First of all, get to know your operations department. Make friends with them. Invite them along to your retrospectives and showcases. Learn the tools they use. Help them build new ones. Read books like Release It! that talk about how to create production-ready software. Check out the screens they have up that show off production metrics. Get the same screens put up in development rooms (LCD panels are cheap these days). Ask to help out when releases happen. Get involved.


Can you talk about your job at ThoughtWorks?

I'm working on a number of things. On the one hand I am doing a lot of travelling at the moment, going to conferences and talking to our customers. I'm also doing some research and writing, including working on a series of interviews to create some videos about continuous delivery. Finally I'm doing some consulting work to make sure I keep my feet on the ground and stay in touch with the latest developments in the space, and of course to pay my way.

------------------------------------------------

Jez Humble is a Principal at ThoughtWorks Studios, and author of Continuous Delivery, published in Martin Fowler’s Signature Series (Addison Wesley, 2010). He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services, and online retail companies. His focus is on helping organisations deliver valuable, high-quality software frequently and reliably through implementing effective engineering practices.

Perguntas Frequentes sobre Agilidade

Em Julho deste ano, após o mini-curso que dei na Globalcode sobre Scrum + XP, uma das pessoas presentes, meu amigo Orlando, anotou diversas perguntas sobre Agilidade no formato de entrevista e pediu que eu respondesse por email.
Segue abaixo algumas perguntas que achei interessante, e resolvi publicá-las aqui no blog.

O que é ser ágil nos dias de hoje?

Acho que ser ágil nos dias de hoje é saber aproveitar as oportunidades de inovação no seu ambiente de trabalho, percebo que a maioria das pessoas acabam ficando acostumadas com a rotina de seus afazeres e perdem chances de inovar.
Quando digo inovar, digo que existem várias maneiras de você introduzir no seu dia a dia práticas ágeis. Outro ponto importante em ambiente ágeis é a comunicação, para ser ágil a pessoa saber lidar com pessoas, com o cliente, e ter um relacionamento de parceria, não pode ter medo de se expor e ser comprometido.
Comprometido não é trabalhar 250 horas por mês no projeto, é saber assumir responsabilidades e saber responder por elas, não ter vergonha de pedir ajuda na hora de uma dificuldade. É velha a história do porco e da galinha =).

Quais os pontos fracos das metodologias ágeis?

O que vejo como um ponto fraco em metodologias ágeis, pela sua própria natureza lean, ou seja, enxuta. É que fica um pouco difícil a sua adoção em ambientes que haja modelos de governança de TI como o Cobit, por exemplo. É difícil em um ambiente de Governança "certificado", você justificar para o gerenciamento de projeto o uso apenas de quadros e post-its, entende? Isso eu digo principalmente com Scrum e XP.
Neste tipo de cenário, a empresa tende a escolher modelos híbridos baseados no PMBook e RUP. O que no final acabam se tornando processos altamente burocráticos em cascata.
Por isso, que acho que esse é um campo que tem muito a ser explorado, trabalhei cerca de 2 a 3 com RUP, e uma escolha mal feita nos artefatos de projeto acaba comprometendo e muito o rendimento da equipe
Outro ponto fraco é o próprio agilista, que tende a pensar que é o dono da razão, pois a verdade é que Barry Boehm já falava da importância dos métodos iterativos (  que vieram bem antes do movimento ágil ).

Quando não usar?

Bem, independente do lugar que você esteja é muito importante praticar, aplicar os valores do Manifesto Ágil.
Eu não consigo enxergar o uso de métodos ágeis em projetos de implantação de ERP (pacote comprado), principalmente quando a implantação é feita em grandes empresas com diversas filiais. Geralmente, as empresas fornecedoras deste tipo de software já possuem métodos próprios.
Outra ponto, é se a sua empresa desenvolve software e seu cliente esta feliz, o desenvolvedor esta feliz, os projetos estão sendo entregues no prazo, o ROI esta dentro das expectativas, o Time-to-market do seu produto é baixo e a equipe é produtiva, se neste cenário você já não estiver usando ágil, fique onde está.
Se o seu processo de desenvolvimento esta atendendo plenamente você e seus clientes, então não mude. Você já esta no caminho certo.

O que mais dificulta a implantação de uma metodologia ágil numa empresa atualmente?

Com certeza o que dificulta a implantação de métodos ágeis nas empresas é a própria filosofia de desenvolvimento da empresa. Por requerer uma mudança radical na forma de lidar com o desenvolvimento de software, é difícil alcançar uma plenitude na implementação de métodos ágeis e isto pode afetar sua adoção, é difícil as pessoas envolvidas na definição de processos da empresa admitirem que estavam fazendo algo que é não muito produtivo, e que a maneira que elas desenvolvendo software não é a melhor.
Outros pontos que dificultam a implantação de métodos ágeis, ainda alinhado ao primeiro item é a falta de um sponsor, como um diretor, ou outro cargo executivo, se agile não está "vendido" para a alta cúpula da empresa, então pode haver muita resistência por conta da própria TI.
E por fim, a falta de comprometimento da equipe e a falta de conhecimento em métodos ágeis podem dificultar também a implantação.

Só serve para projetos? E a manutenção do sistema?

Agile proporciona um leque bem variado de métodos, entre eles FDD, Scrum, XP, Lean, Crystal, entre outros. Eu diria que os dois caminham juntos, a questão gira em torno de como você irá administrar e classificar os itens em seu backlog.
A partir do momento que um release do seu produto entra em produção, é natural que novas demandas e até bugs apareçam. Tem empresas que separam equipes para atuar somente em projetos de manutenção e outras equipes para trabalhar somente em projetos de evolução, depende tudo de como o trabalho é priorizado.
Para áreas de serviço, como Infraestrutura, onde a atuação das equipes geralmente é feita sob demanda, é recomendado o uso de quadros Kanban, inclusive atualmente estou fazendo um trabalho neste sentido (Quadros Kanban para áreas de Infraestrutura).

E a arquitetura do sistema, como fica?

Essa é uma questão polêmica e que gera muitas dúvidas para quem está iniciando no mundo ágil, principalmente para as pessoas que estão em transição de um método como o Waterfall para o Ágil.
Quando o time de desenvolvimento vem do Waterfall ou até mesmo do RUP, que é um método que descreve os artefatos necessários para se documentar a arquitetura do projeto e propõe um modelo "big design up front", ou seja, força o time tentar imaginar e fechar todos os modelos no inicio da execução do projeto.
Em processos ágeis isso acontece de forma natural e evolutiva, uma das práticas do XP, o "Simple Design" ou "Design Simples" nos diz para mantermos o nosso design o mais limpo e simples possível, e não tentar imaginar funcionalidades que o sistema possa vir a ter, e preparar o sistema para estes prováveis cenários. Isso foge completamente do modelo ágil de gerir projetos.
Independente do modelo que você segue, o seu sistema obviamente será construída baseada em uma arquitetura, e em toda metodologia é muito importante você fazer o planejamento da sua arquitetura, a diferença é que em métodos ágeis devemos sempre respeitar a maturidade atual do projeto de modo que quando houver mudanças ou adição de novos requisitos do negócio, fique fácil refatorar o sistema, levando sempre em consideração os requisitos de qualidade de serviço (QoS) conhecidos por todo arquiteto,

Como fica o contrato? Não há prejuízos para a produtora, uma vez que o cliente altere constantemente o que foi inicialmente solicitado?

Acredito que não, um dos valores do manifesto ágil diz que a colaboração com o cliente é mais importante do que a negociação de contratos, por que isso? Se olharmos para a maneira como as empresas negociam os contratos de software com as consultorias, veremos que esta é uma eterna luta. Porque as empresas adotam o modelo de "Preço Fixo" e para uma consultoria entrar em uma empresa, ao formular uma RFP ela acaba colocando valores que muitas vezes ela mesma sabe que pode tomar um prejuízo, mas o faz para ganhar o cliente.
Este tipo de contrato é ruim, pois passa a maior parte do risco para o desenvolvedor, se o projeto atrasa, o consultor arca com os custos, o que dificulta (e muito) mudanças de escopo.
Um modelo de contrato que achei muito interessante é o modelo "Money for Nothing, Changes for free" proposto por Peter Stevens em http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts#MFN-cff.

Qual o maior benefício (a longo ou curto prazo) que um funcionário (desenvolvedor, tester, analista, etc.) obtém quando se compromete a seguir uma proposta ágil?

Desenvolvedores geralmente gostam de agile, porque os métodos são voltados para times auto-gerenciáveis. Modelos ágeis dão uma liberdade maior aos membros do time, então acho que o maior benefício é o próprio bem-estar do time. Sem falar dos ganhos da empresa como a melhoria contínua da qualidade, redução do risco de entrega e do time to market, aumento da visibilidade do projeto, entre outros.

Como ser um Scrum Master?

Na minha visão, para ser um Scrum Master é preciso antes de tudo saber lidar com pessoas, isso é fundamental, além disso, precisa ser uma pessoa comprometida e responsável, que entenda os requisitos do negócio e as necessidades do time.
Tem que ser uma pessoa humilde, e que saiba influenciar a equipe de maneira positiva, com uma cultura de colaboração.

Como as empresas do Brasil estão aceitando a XP?

Hoje em dia é moda falar de Agilidade no Brasil, principalmente no meio dos desenvolvedores. O que vejo é que é um assunto muito falado, mas pouco aplicado.
XP tem sido assunto em roda de conversa de desenvolvedores durante muitos anos, e o que acaba sendo feito neste sentido são movimentos individuais de desenvolvedores que aplicam algumas práticas do XP de maneira isolada, principalmente TDD.
Com o advento e a popularidade do SCRUM, pessoas de outras esferas nas empresas estão começando a olhar agile de maneira diferente, e tem havido uma grande aceitação neste sentido, então acho que isso tem sido bom para XP também.

Dê algumas dicas de boas práticas àqueles que estão iniciando (estagiários e estudantes).

A melhor dica que posso dar é a mesma que dou em minhas apresentações quando sou indagado. Que é estudar, e tentar se manter bem informado sobre o que está acontecendo no mercado. É impressionante o que você consegue fazer com os feeds dos websites, busque os melhores sites e agregue-os em ferramentas como o Google Reader ou outro leitor de feed qualquer, isso potencializa muito o conhecimento.
Participe de lista de discussões, veja cases de implantação tanto de sucesso quando de insucesso e buscar ler o máximo que puder sobre o assunto.

Finalize com uma mensagem para aqueles que estão interessados, mas ainda são céticos.

Faça uma prova de conceito, e se possível procure implementar ao menos uma prática ágil. Uma dica que dou é sempre que possível, traga o cliente para o lado do desenvolvimento, se você puder fazer com que seu cliente avalie o produto que você está desenvolvendo semanalmente ou até de 15 em 15 dias, você irá começar a ver os ganhos do desenvolvimento ágil.
Ou ainda, vou ir totalmente contra o que acabei de falar, sempre que olhar para o seu processo atual de desenvolvimento, antes de tentar adicionar qualquer prática ou passo novo (menos a que citei sobre o cliente), exclua uma etapa do seu processo. Monte um gráfico de cadeia de valor dos seus processos, e analise o que você pode excluir de passos do seu processo. Se você fizer isso, você já está no caminho de se tornar um grande agilista!

Entrevista para a Globalcode

No mês de Junho, foi publicado uma entrevista minha para meus caros amigos da Globalcode, sobre carreira e oportunidades, para quem não viu vale a pena conferir. Segue abaixo as perguntas que estão disponíveis no próprio site da Globalcode. Para quiser ver o link da entrevista, clique aqui.

1. Poderia nos contar como começou a desenvolver plugins para o Netbeans ?

Comecei a desenvolver plugins através do "Desafio NetBeans", um campeonato de desenvolvimento de plugins para o NetBeans patrocinado pela Globalcode, Sun e o SOUJava, me lembro que antes de iniciar o campeonato participei de alguns minicursos gratuitos promovido pela Globalcode, contando inclusive com a participação de dois desenvolvedores do NetBeans (Tim Boudreau e Charlie Hunt).
Neste campeonato desenvolvi meu primeiro plugin para o Netbeans, mais especificamente um plugin para o Hibernate, onde a partir de tabelas selecionadas de um Banco de Dados, o plugin gera as entidades de persistência, o arquivo de configuração, com suporte a xDoclet (na época não havia annotations). Neste primeiro contato com a plataforma NetBeans tive a oportunidade de aprender várias coisas legais que me motivaram a continuar o aprendizado.

2. Desde então, quais plugins você já desenvolveu?

O segundo plugin que desenvolvi foi o módulo CodeGen, um plugin para sobrescrever os métodos equals() e hashcode() que na época (NetBeans 5.0) não existia no NetBeans, e existia no Eclipse. Existe até uma história engraçada por trás disso, me lembro de estar em um minicurso em que o Vinicius comentou que abria o Eclipse apenas para utilizar a função do equals e hashcode, o que me motivou a criar este projeto =D.
Depois desenvolvi alguns plugins corporativos, e depois de um tempo, a pedido do meu amigo Renato Bellia, criei o plugin Diamond Powder for NetBeans. No evento Yahoo Open Hack Day desenvolvi junto com o time Globalcode o plugin Blueprints Yahoo!, e mais recentemente estou colaborando na criação de um plugin para o framework SuperCRUD para o meu amigo Vinicius Senger.

3.Poderia comentar um pouco sobre o plugin que você desenvolveu no Yahoo Open Hack Day onde participou da equipe que ganhou o prêmio Bridging the Gap ?

Para mim foi uma grande alegria e honra participar do time Globalcode, onde ao todo foram desenvolvidos 4 hacks. Sobre o plugin desenvolvido para o Yahoo Open Hack Day, é um módulo que permite a criação de projetos (através de templates) com suporte ao Yahoo! Blueprint, uma tecnologia desenvolvida pela Yahoo que permite a criação de web sites para celulares com uso apenas de XML. O plugin oferece a criação de um esqueleto para um projeto Yahoo, criando os arquivos necessários para seu funcionamento (gallery.xml e config.xml). Além disso, o plugin vem com alguns samples (desenvolvidos pela Globalcode) dentro do NetBeans para os desenvolvedores que querem entender como funciona um projeto Blueprint. E possui suporte a Update Center, Help, e a inclusão do guia do Desenvolvedor em pdf no NetBeans.

4. Quais os conhecimentos necessários para um programador começar a criar módulos para o NetBeans ?

Além de ter conhecimentos sólidos de Java Standard Edition, para o programador iniciar a criação de módulos para o NetBeans, é importante entender como funciona o NetBeans e a sua arquitetura. Procurar enxergar além do IDE, rs.. o IDE NetBeans é construído sobre a Plataforma NetBeans, assim como vários outros produtos, como por exemplo a ferramenta VisualVM, quem utiliza nota a grande semelhança com o NetBeans.
Ao iniciar o desenvolvimento na plataforma NetBeans, já temos disponíveis várias funcionalidades / componentes prontos para o uso e toda esta infraestrutura pode ser manipulada via código através das APIs da Plataforma NetBeans. A plataforma dispõe de APIs para trabalhar com diversos tipos de categorias entre os quais podemos destacar como as Ações do Sistema (Actions), Ant, Paleta de objetos, Debug, Dialogs (para notificação), Sistema de Janelas, Sistema de Arquivos, Editores, Navegação, Loaders, entre outros.
O programador precisa somente entender como manipular estas APIs que ele pode praticamente fazer o que quiser com o NetBeans.

5. Sabemos que você andou fazendo testes com Zembly, poderia comentar um pouco sobre o que é Zembly e para que serve ?

A ideia do Zembly, é criar uma espécie de Wiki para aplicações sociais como o Facebook, ele fornece o ambiente no próprio site do Zembly para criação e edição de aplicações sociais, essa aplicação fica hospedada em uma nuvem do Zembly de maneira que podemos compartilhar nossa aplicação entre diversos sites, como se fossem widgets.
É algo extremamente interessante, pois no Zembly, temos um editor para o código HTML/XHTML para UI, um editor CSS para aplicar os estilos da aplicação e um editor JavaScript para a lógica do negócio, que pode ser utilizado bibliotecas JavaScript como jQuery, Prototype e podemos fazer inclusive integração com diversas APIs como FlickR, Yahoo API, Google Maps, entre outros.
Atualmente estou trabalhando no SOUJava para criar uma aplicação que seja compartilhada pelos sites de tecnologia, fóruns, blogs, de maneira que o SOUJava possa divulgar suas atividades de uma maneira muito mais ampla, pois estes sites deverão apenas incluir um pequeno trecho de código JavaScript em seus sites.

6. Poderia comentar um pouco sobre o Plugin que desenvolveu como colaboração para o SuperCRUD ?

Na verdade, este foi um trabalho relâmpago que montamos para o SuperCRUD e está em evolução, atualmente o plugin permite a criação de qualquer tipo de projeto (web, desktop, maven) com fontes existentes a partir de um servidor remoto, onde o desenvolvedor precisa informar a URL para o projeto (zipado).
Pelo que sei, o desenvolvedor cria um projeto no SuperCRUD, e ao final o próprio SuperCRUD gera uma bookmarkable URL que o programador cola e copia no NetBeans (no plugin), que por sua vez abre o projeto remotamente. Mas claro, sobre esta parte do SuperCRUD o Vinicius poderia dar maiores detalhes =D.

7. Poderia comentar um pouco sobre o Plugin que fez para o projeto Diamond Powder junto com o Renato Bellia?

O Diamond Powder é um framework open source para Java ME desenvolvido pelo Bellia, que acelera a criação de coletores de dados em aplicações MIDP. O framework permite a criação dos formulários, fields (datafield, stringitem, textfield, choicegroup, filter, etc..), definição do fluxo de navegação das páginas e as páginas de help de maneira declarativa, baseada em definições de pares de chave-valor com uso de um Hashtable, que descreve toda a sua organização por um objeto chamado Schema.
O "Schema" é o coração do framework, mas conforme a sua aplicação cresce, fica cada vez mais difícil dar manutenção no seu Schema, como adicionar novas páginas e campos, e é onde o plugin entra, ele facilita muito a criação e a manutenção do código do Schema (com refactoring ou criação de uma nova classe) através de um wizard e evita a digitação errada dos nomes das váriaveis, campos.
Tem a possibilidade de gravar os dados criados (páginas, campos, etc...) em um arquivo properties e reutilizá-los em outros projetos.

8. Você realmente achou um nicho de mercado muito interessante, onde pode colaborar com praticamente qualquer projeto Open Source, quais as dicas que você poderia dar para as pessoas que estão iniciando?

A melhor dica que posso dar é estudar, estudar e estudar. Porém, se você ficar cansado de estudar, estude mais um pouco, faça cursos de java, visite sites de tecnologia como InfoQ, TheServerSide, execute os samples disponíveis no NetBeans e analise o código fonte, participe das listas de discussão. Participe dos eventos, dos minicursos, inscreva-se em todos os feeds possíveis sobre tecnologia, blogs, participe de grupos de discussão, tire certificações e o mais importante, participe de projetos open source, além de aprender com profissionais renomados e compartilhar conhecimento, você estará fazendo networking, sem falar da possibilidade do seu trabalho ficar conhecido no mundo todo.

9. Poderia citar algumas referências para quem quer começar a desenvolver plugins para NetBeans ?

Para as pessoas que estão iniciando, recomendo o próprio site do NetBeans Platform que possui diversos tutoriais, screencasts, wikis, samples que demonstram como criar módulos para o NetBeans, recomendo também o blog do Geertjan, um dos desenvolvedores e evangelista do NetBeans, e existe um livro excelente chamado Plugging into the NetBeans Platform, que apesar de ser de 2007 demonstra em detalhes a criação de módulos para o NetBeans e o uso correto das APIs. E também recomendo meu artigo que foi publicado na edição 29 da revista Mundo Java sobre a Plataforma NetBeans ;).

10. Poderia citar algumas referências para quem quer começar a estudar Zembly?

Para começar a estudar Zembly, o mais importante é conhecer bem JavaScript, (X)HTML e CSS, o resto é entender como funciona o ambiente do Zembly.
Uma ótima referência é o wiki do site, que possui diversos tutoriais de como criar aplicações a partir de templates, criação de aplicações para o Facebook, iPhone, Meebo, entre outros.