Archives pour l'étiquette devops

Devoxx France 2016

keynote_devoxx_fr_2016_03

Once again Devoxx France took place at the « Palais des Congress » in Paris from April 20 to 22 2016.
 
Devoxx France is part of the family Devoxx conferences (Belgium, England, Poland, Morocco). The community includes over 10,000 developers worldwide.
It was created in 2012 by the association of the Paris JUG. With 2,500 people in 2016, is one of the conferences for the most important developer. If DNA Devoxx France is the Java platform, conferences are also open to other themes such as mobility, Web, Cloud Computing, Mobile, etc.
238 speakers, 220 conferences, and of course a lot of information on IT development for this 5th edition of Devoxx France.
Also a village of exhibitors welcome visitors all the day between the conferences.
Capture d’écran 2016-05-24 à 10.06.56
What are the subjects
The various conferences are split into different types:
  • Keynotes : Opening plenaries of the days on large thematics (innovation, future, security, women in IT…)
  • Conferences45 minutes of presentations on technical subjects (most common type of conference)
  • Universities : 3 hours presentation, took place the first day
  • Tools in Actionshort sessions of 25 minutes, intended to present a tool, a practical software or solution
  • Hands-on Labs : practice session of 3 hours, in rooms 25 to 60 people
  • Quickiesshort sessions of 15 minutes during lunch
  • BOF (Bird of a feather) : point of rendezvous of user-groups, communities, meet ups….
All conferences are based on thematic tracks. The different tracks to suggest a topic:
  • Java, JVM, Javas SE / EE : About Java, JVM, Java SE, Java EE.
  • Mobile and Internet of Things : Mobile, Java and the Internet of Things, home automation and embedded systems.
  • Web, HTML5 and UX :  user-experience, front-end and web architecture.
  • Architecture, Performance & Security : Architecture, performance, encryption and best practices for developing secure software.
  • DevOps, Agility, Methodology & Tests : Methods and development practices / software deployment, TDD, BDD, xDD.
  • Cloud and Scaling : Cloud-computing, resilient architectures, containers
  • Big Data and Analytics : Store, analyze the data and revise the management of data.
  • Future Robotics :  Robotics and Computing for Tomorrow
  • Alternative languages : Groovy, Scala, GB, JavaScript, Clojure, Haskell, Haskell, Ceylon, etc.
As you can see, the topics are very Java / Mobile / Web oriented, with a large place to DevOps and Cloud.
It is impossible to make aa summary of all Devoxx conferences.
Here we will try to focus on the main informations provided by the conferences.
You can have a look at the Youtube playlist of Parleys to check the recorded conferences:
static1.squarespace.com
Information held
Micro-services, Java and its future, Mobile development industrialisation and Web development future were the main ideas of this Devoxx edition.
DevOps was the underlining idea between them. In a way, there is no more doubt that DevOps must be applied everywhere and in any cases (Java backend development, Mobile, Web…). Tools can change a little, but the need is quit the same : acceptance and delivery must to be automated. We could heard DevOps in any conferences, what ever the technology was.
The same way, concerning application and mainly backend architecture, the underlining assumption was that you are doing Cloud development, API and Micro-services. Micro-services are the main wave of architecture associated to DDD (Domain Driven Design) as a development approach.
Bind to DevOps and micro-services, Docker confirmed once again is major influence to IT innovations.
Of course a lot conferences covered various other subjects, but these 3 concepts (DevOps, Micro-services, Containers) lead the majors ones.
devoxx
Picking some conferences
Here are some informations extracts from various conferences.
E2784607-E83E-445C-BF7D-D319519281FF
« Architecture Android et bonnes pratiques »
Mathias Seguy, an Android expert shows best-practices, tools and examples on Android development.
He recommended a lot of Square librairies like:
  • Retrofit (Type-safe HTTP client)
  • Akio (A modern I/O API)
  • Moshi (A modern JSON library)
  • Okhttp (An HTTP+HTTP/2 client)
  • Leakcanary (memory leak detection)
  • Dagger (dependency injection, see below)
As an event bus he recommended:
  • Otto
  • Eventbus
Very important in Android developments:
  • Analytics
  • Tests
For testing purpose he recommend:
  • Dagger dependency injection
  • Mockito with Espresso for UI testing
  • Leakcanary for memory leak detection
  • Genymotion emulator (cloud offers are available)
In his opinion, Kotlin and RxJava are interesting things to see for the future of Android developments.
See his presentation:
26E2AAF5-4034-4FA4-9DB0-6F9F00D17166
« Microservices IRL: ça fonctionne chez un client, on vous dit comment! »
Stéphane Lagraulet and Olivier Revial present return of experience on developing and stepping micro-service at their client.
They explain the choice of micro-services by a convergence of moves associated to Agile, DevOps, answer to complexity, Web Architecture, Cloud, Containers and provisioning.
Challenges were the organisation, service discovery, monitoring, distributed development, resilience, test, strategy, versioning management, and continuous delivery.
They explain also anti-patterns like : do micro-services are really a necessity in our context? Distributed monolith, distributed transactions.
Technically, they developped micro-services with Spring Boot. They used tools like Zookeeper for service discovery, Zabbix for monitoring, Curator/Zookeeper for distributed development, Hystrix for circuit breaker. They use also Spring Cloud Zookeeper, and Spring Cloud Netflix (to integrate with Zulu).
For testing purpose, they use some RestTemplate, with WireMock or Saboteur. Gatling for performance tests.
Deployment is done by Ansible cookbook, executed by Jenkins.
But in the roadmap, they expect to deploy services with Spinnaker, Docker and Mesos.
They think about making study on Eureka or etc/CoreOs for service discovery.
Also, for communication between micro-services they will study Protobuf, Avro and Thrift.
See their presentation:
024085CF-7B53-4341-9311-0D8C8F1A9AC8
« Jenkins, Docker Orchestrons le Continuous Delivery »
Nicolas de Loof,  Yoann Dubreuil make a presentation on setup a delivery pipeline with Jenkins and Docker.
The goal here is to make a demo on continuous delivery orchestration.
They announce Jenkins 2.0 is out.
With Jenkins, pipeline of delivery was quit difficult to maintain, because of lots of plugins to use.
Here the speakers expose a solution to simplify the pipeline.
The Build Flow plugin allows to define the jobs through a DSL. The plugin act as an orchestrator.
But there is too much dispersion of information (separate jobs).
The other solution is to use the Pipeline Plugin, which allow to use a pipeline script (DSL) to define the build but also all the stages of the pipeline (Dev, QA, Prod…).
With the use of JenkinsFile the DSL file description is in the SCM and Jenkins will use it directly. This way we can have versioning of the Job configuration.
The CloudBees Docker Custom Build Environment Plugin allow to use Docker image as slave of build.
The JenkinsFile can also use Docker image to specify where to build the application.
The Multi-branch plugin allows Jenkins to detect all the branch where there is a JenkinsFile and create a job associated.
See their presentation:
Wrap-up
Devoxx is a great conference moment, where you can get huge IT innovation information and share with other visitors and speakers.
Many conferences here confirm the big movement felt 2 or 3 years ago:
A global association between Agile, DevOps, Micro-services architecture, DDD, Docker containers and Cloud.
More information

Monitoring : a DevOps need

DevOps and Agility are continuous improvement oriented.
How can you have continuous improvement without the ability to measure improvement? How do you know if an automation task is worthwhile? Basing decisions on data, rather than instinct, leads to an objective, blameless path of improvement. Data should be transparent, accessible to all, meaningful, and able to be visualized in an ad hoc manner.

A DevOps need

DevOps is not a method, but a culture shift. The main principles very commonly used are the CALMS:
Culture, Automation, Lean, Metrics, Sharing
Here the Measure is our focus :
Metrics (or Measure) — A metrics-oriented mindset is key to ensure that DevOps initiatives taken up by infrastructure and operations leaders deliver the intended results. IT organizations should focus their measurement efforts on five primary domains: IT operations, the service (or application), the organization as a whole, the customer, and the business. Goals should be service-focused, with an eye toward improving agility (velocity) and improving business value (quality).
Here we talk about monitoring, which is clearly not a NEW thing, but a necessity which is today more widely needed.
API delivery, Front and Mobile backend deployment, Micro-services : in order to keep control on data management and performance capacity, the need of monitoring is increasing drastically.
On a Cloud (private or public) architecture, monitoring of applications and services are a most needed feature.
But more widely, monitoring application is not anymore a Run or Production only need, but also a development need.
We need to setup a common architecture were monitoring setup should be as easy as instantiate a new service in a cloud management, and since the development phase.

How does it work

Monitoring could be split in 4 main features :
  • produce logs (create data)
  • process logs (understand the data)
  • store metrics (give access to the data)
  • visualize synthesis (explain the data and its evolution)
Capture d’écran 2016-05-12 à 17.25.59

Produce logs

The first step is, of course, applications or services providing data (logs, messages, metrics).
Applications must have capacity to produce data.
This feature is quit already available in most cases by plenty of log systems:
  • syslog format logs : very popular in GNU/Linux / Unix systems
  • raw text logs
  • Apache and Log4j logs
  • Windows Event Logs
  • JSON format messages
  • Queue message (RabbitMQ, ZeroMQ)
These data should be transmit to a central processor.

Process logs

Data produced by applications must be processed to keep the important information.
Often called Data Pipeline, the logs are integrated, analyses, normalized and stored.
The process of the logs is the main feature of monitoring because it should expose the relevant information of the system.
The log processing should flexible enough to adapt to any type of input data (by plugins, customization…).
These data should be stored in a centralized database which can search with efficiency.

Store Metrics

Logs processed become metrics. They should be stored in a way they can be accessed and used easily.
The storage must version and give access to the data to bring search, analytics capacity through API for dashboards.
Performance and scalability have a critical point here : we want to access these data in a real-time and with high-availability.
These metrics should be used synthesized in a dashboard.

Visualize synthesis

Logs processed become metrics. They should be stored in a way they can be accessed and used easily.
The dashboard give a synthetic view of the metrics and instant sharing capacity of the situation. It should easy to understand and give access to the relevant information.
The dashboard should be flexible enough to adapt to other needs.

Common Tools

Concerning the development phase, tools like Sonarqube, provide inspection dashboard very useful to improve the quality of the source code.
But concerning visualisation of the service/app state, a monitoring stack should be used to get logs, process and visualize informations.
Several tools are currently used on the market:
  • Elastic Stack (open source – ex. ELK Stack)
  • Splunk (commercial)
  • Graylog (open source)
The tools have to be easy to integrate with common development and potentially agnostic of the language and architecture.
The solution should be easy to integrate with API/Micro-service use cases, and deployable in the cloud.
It should be useable since the development phase (dev/test/integration environments).

Technical illustration

For our illustration we are using the Elastic Stack solution (ex. ELK) which is the most widely used stack.
Elastic Stack: a new name and technology vision for Elastic’s open source products Elasticsearch, Logstash, Kibana, and Beats;
Elastic Stack is the most
In Elastic Stack we have the following role distribution:
  • Process logs : Logstash (Collect, Enrich & Transport Data)
  • Store metrics : ElasticSearch (Search & Analyze Data in Real Time)
  • Visualise synthesis : Kibana (Explore & Visualize Your Data)

Reference

Jamkey press review – April 2016

Dear followers,Swift-Android
here is the 13th press review of Jamkey, which is mainly press review around Continuous Integration, development and DevOps tooling.

As you know, Continuous Integration is not only a way to build automatically, but also a path to development industrialisation.
That’s why you will find here news on Web development, build tools, architecture (API design) but also methods and processes (like DevOps).

 

 

I hope you will find here some interesting information on your current investigations. Most of them are in English, but some are in French.
Don’t hesitate to comment these informations if you think they could be useful for our current challenges.

Build

Devops

Sonar

Web

Mobile

SCM

Cloud

Agile

Architecture

What is DevOps?

DevOpsDaysDevOps (a clipped compound of « development » and « operations« ) is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.

Many of the ideas (and people) involved in DevOps came from the Enterprise Systems Management and Agile software development movements.

 

What is DevOps?

Patrick Debois, (@patrickdebois) godfather of the DevOps movement, always says DevOps is a human problem.

In traditional, functionally separated organizations there is rarely cross-departmental integration of these functions with IT operations. DevOps promotes a set of processes and methods for thinking about communication and collaboration between development, QA, and IT operations.

DevOps is not a technology problem. DevOps is a business problem.

DevOps as a culture, movement or practice which is not a method of development.

It is more a cultural shift where applications are products and not projects. As a cultural change, all the teams are working together to provide a better product in a better time to market. Which means that teams are working together as A product team. Andindustrialization pratices are improved to optimize delivery automation.

 

DevOps integration targets product delivery, quality testing, feature development, and maintenance releases in order to improvereliability and security and provide faster development and deployment cycles.

 

Cultural shift

DevOps-part-dev-part-opsDevOps is more than just a tool or a process change; it inherently requires an organizational culture shift.

This cultural change is especially difficult because of the conflicting nature of departmental roles.

Operations seeks organizational stability; developers seek change; and testers seek risk reduction.

 

Getting these groups to work cohesively is a critical challenge in enterprise DevOps adoption.

 

 

 

Improved automation

DevOpsDays

DevOps is clearly not set of cool tools ! But to escort the cultural shift, automation must be set tooptimize the product delivery.

Automation is a key technical goal of DevOps, specialy practices like build, versioning, packaging, testing (all type of tests), code analysis (quality gate), deployment (to a execution environment), staging, promotion, monitoring.

 

All the SCM practices must be correctly understood and managed in order to get a product from development to production.

But also, tight association between architecture design and SCM is crucial to get the product working!

All the practices involved into set-up a continuous delivery process should be set in order to implement the tooling aspect of DevOps.

 

 

Agile movement

Agile_DevOps_ITIL1

If the goals of DevOps sound similar to the goals of Agile, it’s because they are.

But Agile and DevOps are different things. You can be great at Agile Development but still have plenty of DevOps issues. On the flip side of that coin, you could do a great job removing many DevOps issues and not use Agile Development methodologies at all (although that is increasingly unlikely).

Agile and DevOps are related ideas, who share a common Lean ancestry.

But while Agile deep dives into improving one major IT function (delivering software), DevOps works on improving the interaction and flow across IT functions (stretching the length of the entire development to operations lifecycle).

 

Key goals of DevOps : CAMS

devops-areas-cams

 
CAMS is an acronym describing the core values of the DevOps Movement: Culture, Automation, Measurement, and Sharing. It was coined by Damon Edwards and John Willisat DevOpsDays Mountainview 2010 [1]

Culture

DevOps is mostly about breaking down barriers between teams. An enormous amount of time is wasted with tickets sitting in queues, or individuals writing handoff documentation for the person sitting right next to them. In pathological organizations it is unsafe to ask other people questions or to look for help outside of official channels. In healthy organizations, such behavior is rewarded and supported with inquiry into why existing processes fail. Fostering a safe environment for innovation and productivity is a key challenge for leadership and directly opposes our tribal managerial instincts.

Automation

Perhaps the most visible aspect of DevOps. Many people focus on the productivity gains (output per worker per hour) as the main reason to adopt DevOps. But automation is used not just to save time, but also prevent defects, create consistency, and enable self-service.

Measurement

How can you have continuous improvement without the ability to measure improvement? How do you know if an automation task is worthwhile? Basing decisions on data, rather than instinct, leads to an objective, blameless path of improvement. Data should be transparent, accessible to all, meaningful, and able to be visualized in an ad hoc manner.

Sharing

Key the success of DevOps at any organization is sharing the tools, discoveries, and lessons. By finding people with similar needs across the organization, new opportunities to collaborate can be discovered, duplicate work can be eliminated, and a powerful sense of engagement can be created among the staff. Outside the organization, sharing tools and code with people in the community helps get new features implemented in open source software quickly. Conference participation leaves staff feeling energized and informed about new ways to innovate.

 

What DevOps is not !

shouldnotdo

DevOps is not a set of tools

When speaking about DevOps, very often the subjects are going into « which tool can do that« . But DevOps can not be simpy resumed to that. Because its best improvement is to change the culture of organisations to make them think about product and not projects. Tools are required to automate the delivery but are not the value of the product.

DevOps is not a plan

Some of the early Devops thought leaders started noticing a trend that was particularly emerging from Agile based web operating (Webops) companies.

The observations were that some traditional enterprises were running Agile and Lean development cycles, but their operations still looked like the waterfall process.  They started writing blog articles and they even created a small barcamp style conference called Devopsdays.

DevOps is not exclusive

Some might be extremely excited about the fact that they can deploy 20 times a day; however, just because they can, doesn’t mean that others should or even can.

Devops and process standards are not mutually exclusive. The idea is not to make another silo!

DevOps is not just a bunch of really smart people

Yes, there are some iconic like people involved in the Devops movement. But just like open source, the best and the brightest inventions and great ideas come from a a smaller group and then larger groups adopt and benefits.

Devops is not a product

If a vendor tells you that they have a Devops product or a Devops compliant product, then you will know immediately that they don’t have a clue of what Devops is. However, you know the true followers when they start talking about the Devops culture first and then their tool as a second-class citizen behind people and process.

Devops is not a run around traditional IT

When a Devops discussion starts with technology, the conversation is headed in the wrong direction.  If you hear something like “Just hire smart people and give them root”, immediately run for the hills.

Video presentation

Here is a video presentation on DevOps which summarize in 7 minutes the different pain points and benefits.

Be careful with the slogan: « new tools » could be also « optimized tools ».

Sources

Jamkey press review – March 2016

Dear followers,Agile-Marketing
here is the 12th « Technical News » of Jamkey, which is mainly press review around Continuous Integration, development and DevOps tooling.

As you know, Continuous Integration is not only a way to build automatically, but also a path to development industrialisation.
That’s why you will find here news on Web development, build tools, architecture (API design) but also methods and processes (like DevOps).

 

 

The Devoxx France 2016 program is available !

 

A focus on Gradle 2.11 Continuous Build new features.

Jenkins has released updates that include important security fixes: 1.650 and 1.642.2.

 

Also interesting information about the First Preview of Android N (Developer APIs & Tools) from Android Developers Blog.

 

An interesting article on Why Agile works:

I hope you will find here some interesting information on your current investigations. Most of them are in English, but some are in French.
Don’t hesitate to comment these informations if you think they could be useful for our current challenges.

 

Build

DevOps

Sonar

SCM

Web

Mobile

Agile

Cloud

Java & Architecture

Jamkey press review – February 2016

Dear followers, devops-hidden-ally-velocityconf-ux-devops-empathy-1-638

 

here is the 11th « Technical News » of Jamkey, which is mainly press review around Continuous Integration, development and DevOps tooling.

As you know, Continuous Integration is not only a way to build automatically, but also a path to development industrialisation.
That’s why you will find here news on Web development, build tools, architecture (API design) but also methods and processes (like DevOps).

 


Gitlab explained their strategy and delivered a 8.4.4 version of their open source forge.


Backelite provide a first version of a new Sonarqube free plugin to analyse Swift code.


You will find also comparisons on AngularJS 1 and AngularsJS 2

I hope you will find here some interesting information on your current investigations. Most of them are in English, but some are in French.
Don’t hesitate to comment these informations if you think they could be useful for our current challenges.

 

Devops

SCM

Jenkins

Sonar

Nexus

Web

Mobile

Agile

Cloud

Architecture

Technical test strategy

test-tubeAutomated test strategy is one the key factors of technical tests. Its visibility make the tests part of the development process.Without goals, roles, tools, requirements, scheduling… the automated tests are forgotten deep in the versioning system…

As written in the ISTQB Exam Certification:

The choice of test approaches or test strategy is one of the most powerful factor in the success of the test effort and the accuracy of the test plans and estimates. This factor is under the control of the testers and test leaders.

By describing, managing and tooling-up the different automated tests you will define your strategy.

This global strategy page gives main clues to manage your technical test strategy.

To have a relevant test strategy make it visible.

 

What is a test strategy?

A test strategy is an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

Test strategies describe how the product risks of the stakeholders are mitigated at the test-level, which types of testing are to be performed, and which entry and exit criteria apply.

They are created based on development design. System design is primarily used and occasionally, conceptual design may be referred to. Design documents describe the functionality of the software to be enabled in the upcoming release. For every stage of development design, a corresponding test strategy should be created to test the new feature sets.

The test strategy describes the test level to be performed. There are primarily three levels of testing: unit testingintegration testing, and system testing as you can read in the Automated test classification.

In most software development organizations, individual testers or test teams are responsible for integration and system testing when dealing withfunctional behavior. Here we speak more of Acceptance tests or Functionnal tests (for example based on HP QC and executed with UFT (ex QTP).

The developers and test experts are responsible for automated tests on unit testing, integration testing, system testing.

Test classification

The automated tests should first be classified in order to be used and integrated into a industrialized process. Please look at the test classification page: Automated test classification

test-classification

Lack of test strategy issues

The common issues with automated tests are not associated to technical problems or the choices of tools, but resides especially in its non-visibility.
When the added value of technical tests is not visible, the organisation will give advantage on more « quantifiable tests » (like functional tests or performance tests) and give-up on technical ones (unit, integration…).

For example, the functional tests are easily quantifiable: dedicated “testing” teams, based on the requirements, test plan in QC, instrumentalisation by UFT (ex QTP) by VB script.
This way, it is easier to give budget to: handle, manage and implement functional tests.

Technical tests remain with the costs of the developers. Because very often, one will say the developers “will make the unit tests” but without real requirements or strategy.

 

Agile projects and using the BDD reverses this trend by bringing closer the Dev and Test teams. Especially when requiring the developers to implement the acceptance tests.

By making the technical tests part of the test strategy, we will improve their development requirements and make them more relevant.

 

Set up a test strategy

The goals to define a test strategy are the following:

Goals

  • Application coverage objectives
  • Set-up a test maintenance plan
  • Have a source code health feedback
  • Use tests as delivery acceptation
  • Verify features non-regression
  • Maintain source code knowledge

Automated test strategy steps

Step
Description
Define Scope and Technology
  • Define perimeter to test (Backend, Front, Data, Integration, Middleware…
  • What technology is involved (Java backend, Java Web, front JS, Mobile iOS…)
  • Roles and Responsibilities of test leader, individual testers, project manager
Define Test Approach

Choose by what type of test starting

Use Test classification

  • Unit Testing
  • Integration Testing
  • System Testing

What relevant coverage is expected ?

What test volume is expected ?

Choose a test development methodology
  • Technical requirements
    • Requirements specifications
    • Requirements traceability matrix
  • Test priorities
    • While testing software projects, certain test cases will be treated as the most important ones and if they fail, the product cannot be released.
  • Choose methodology (eg.: BDD)
  • Batch mode execution
  • Execute in continuous integration
  • Execution scheduling
    • A test plan should make an estimation of how long it will take to complete the testing phase.
  • Mock policy
Identify risks and mitigation
  • Risk occurence anticipation :
    • Any risks that will affect the testing process must be listed along with the mitigation
Define Test environment
  • Hardware requirements
  • Middleware requirements
  • Workstation needs
  • Environment provisioning
Choose Testing tools
  • Test framework which suit development technologies
  • Test orchestration
  • Integration with continuous integration
  • Integration with delivery process
  • Tests record and reporting
Define Execution and release control
  • Execute automated tests plan according to release control
  • Use test plan to validate release
  • Use test plan in a promotion process
  • Regression test approach
    • Regression tests will make sure that one fix does not create some other problems in that program or in any other interface
Defect reporting and tracking
  • How the test result is reported
  • Change and configuration management

 

Set-up Reviews and updates
  • Review the test strategy after milestones
  • Update the test strategy according to feedbacks

Test strategy life-cycle

test-strategy-life-cycle

(Test Strategy in STLC)

 

IT Press review – December 2015

Dear followers,

Logo_Apple_Swift
here is the 9th « Technical News » of Jamkey, which is mainly press review around Continuous Integration, development and DevOps tooling.

As you know, Continuous Integration is not only a way to build automatically, but also a path to development industrialisation.
That’s why you will find here news on Web development, build tools, architecture (API design) but also methods and processes (like DevOps).

 

 
Apple announce Swift open source and a 3.0 version with a package manager


The story of Instagram development from Mike Krieger point of view.


A clear description of the Security Vulnerability which affect the Apache Commons components.

And link to that a new Jenkins releases with important security fixes : the Apache Commons patch.


An interesting article comparing Angular 1 vs. Angular 2.


An interesting article on the decline of Java application servers when using docker containers

I hope you will find here some interesting information on your current investigations. Most of them are in English, but some are in French.
Don’t hesitate to comment these informations if you think they could be useful for our current challenges.

Architecture

Stories

DevOps

Jenkins

SCM

Sonar

IDE

Web

Mobile

Agile

Cloud

IT Press Review – October 2015

Dear followers,GitLab-logo2

here is the october « Technical News » which is mainly press review around Continuous Integration, development and DevOps tooling.

As you know, Continuous Integration is not only a way to build automatically, but also a path to development industrialisation.
That’s why you will find here news on Web development, build tools, architecture (API design) but also methods and processes (like DevOps).

GitLab 8 is out, with a new UI and new features. As usual the GitLab team still releasing almost every weeks a new version of GitLab. Be careful to stay in tune with this major new version.

HP LeanFT is released and will replace HP UFT according to HP. More oriented to Agile and BDD testing.

There is a proposal from the Jenkins team to switch to version 2.0, with a new UI and design

Internet Explorer pre 11 versions will not be supported anymore since January 2016 : this is the end of a major story!

On the Mobile side, WatchOS 2.0 and iOS 9 are out, with new features on Unit Testing!

I hope you will find here some interesting information on your current investigations. Most of them are in English, but some are in French.
Don’t hesitate to comment these informations if you think they could be useful for our current challenges.

Build & SCM

DevOps

Jenkins

Sonar

Web

Mobile

Agile

Cloud

Architecture

IBM Bluemix and Docker Webinar

Short presentation from IBM Emmanuel Vregille <EMMANUEL@ie.ibm.com> : 16/09/2015 bluemix-docker
Presentation:

  1. Concepts of Docker
  2. BlueMix features
  3. Demonstrations of Docker & BlueMix

 

 

Summary of IBM Bluemix and Docker WebInar

Docker

An open platform for distributed applications for developers and sysadmins.
Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux, Mac OS and Windows. https://www.docker.com/

Docker is a huge success. 68% of CTO and CIO are preparing a Docker study for 2016.

Docker allows : applications independent and portable, optimize resources, faster deployments, adapt to micro-services

Bluemix

Bluemix :

  • deploy and optimize Docker container on Bare Metal
  • bring Management of : images, containers, DockerHubs and DockerEngine

IBM has a partnership with Docker since june 2014

Bluemix provides :

  • a development Hub + development tools
  • a Service catalog to optimize resources
  • deployment / scalability features / Logging / Monitoring
  • as beta features : containers security scans

Bluemix offers 3 main profiles:

  • IAAS with OpenStack => manage VM
  • PAAS with CloudFoundry => cloud applications
  • Docker container => Bare Metal Docker container management

Also a catalog of services is available (for example to get a database).
Local or Public Hub management

API and services oriented.

The JazzHub service manage development forge and release mechanism:
Build Image => Deploy and link to services => Test

Demo

The Demo consists of :

  • building locally a container image of a todolist application
  • deploying the container on the BlueMix Hub
  • Creating MongoDB service from service catalog of BlueMix to manage a bind
  • Use JazzHub to manage the container deployment
  • Run the BlueMix container bind to the MongoDB service
    See Youtube link below to see the demo

Important points

  • IBM changes its strategy and communication and follows the path of all the main actors by using Docker containers: Google Cloud, Amazon, Microsoft Azure, RedHat OpenShift, Heroku
  • IBM embrace with Bluemix and Docker the container architecture with cloud and micro-services
  • Bluemix use mainly OpenSources software inside (OpenStack, CloudFoundry, Docker)
  • By adding the Jazz Hub to the global picture, they bring a development forge AND a release management system (The catalog of BlueMix provide also Delivery Pipeline mechanism)
  • BlueMix can hold other technologies than Java, even for backend

What can we foresee by these choices ?

  • Micro-services
  • API backend (not only Java: Node…)
  • Applications standardized in a DevOps way with Docker

Nextstep