Elsewhere

EvolvisForge blog: Java™, logging and the locale

Planet Debian - mar, 24/02/2015 - 17:02

A coworker and I debugged a fascinating problem today.

They had a tomcat7 installation with a couple of webapps, and one of the bundled libraries was logging in German. Everything else was logging in English (the webapps themselves, and the things the other bundled libraries did).

We searched around a bit, and eventually found that the wrongly-logging library (something jaxb/jax-ws) was using, after unravelling another few layers of “library bundling another library as convenience copy” (gah, Java!), com.sun.xml.ws.resources.WsservletMessages which contains quite a few com.sun.istack.localization.Localizable members. Looking at the other classes in that package, in particular Localizer, showed that it defaults to the java.util.Locale.getDefault() value for the language.

Which is set from the environment.

Looking at /proc/pid-of-JVM-running-tomcat7/environ showed nothing, “of course”. The system locale was, properly, set to English. (We mostly use en_GB.UTF-8 for better paper sizes and the metric system (unless the person requesting the machine, or the admin creating it, still likes the system to speak German *shudder*), but that one still had en_US.UTF-8.)

Browsing the documentation for java.util.Locale proved more fruitful: it also contains a setDefault method, which sets the new “default” locale… JVM-wide.

Turns out another of the webapps used that for some sort of internal localisation. Clearly, the containment of tomcat7 is incomplete in this case.

Documenting for the larger ’net, in case someone else runs into this. It’s not as if things like this would be showing up in the USA, where the majority of development appears to happen.

Catégories: Elsewhere

Sven Hoexter: just because

Planet Debian - mar, 24/02/2015 - 16:51

That inevitable led to this on the office wall.

Catégories: Elsewhere

Annertech: Create the WOW Factor with Drupal - Part 2 of 5

Planet Drupal - mar, 24/02/2015 - 16:30
Create the WOW Factor with Drupal - Part 2 of 5

Yesterday, we began this series with a short introduction to creating the wow factor on a Drupal website. Today we'll look in a bit more detail at (drum roll) ...

Catégories: Elsewhere

Drupalize.Me: Responding to Events in Drupal 8

Planet Drupal - mar, 24/02/2015 - 15:05

Events in Drupal 8 allow various system components to interact and communicate with one another while remaining independent, or decoupled. The event system is built on the Symfony event dispatcher component, and is an implementation of the Mediator design pattern. This post takes an in-depth look at how module developers can subscribe to events in Drupal 8.

Catégories: Elsewhere

Acquia: Acquia Certification Program Ready to Turn 1!

Planet Drupal - mar, 24/02/2015 - 14:55

After many years of discussion and debate in the Drupal community, Acquia launched the Acquia Certification Program in March 2014. This past year, there were three exams published and offered on a global basis with participants from over 45 countries and several hundred earning credentials. The exams focus on real world experience and the overriding comments we've heard this past year are the exams are tough but fair. There is now a registry posting successful candidates as well.

Most credentials have been earned with the first exam, Acquia Certified Developer, a core exam which cuts across Web Development, Site Building, Front-end and Back-end topic areas. This exam demonstrates an ability to work across these key areas, which in turn helps make successful developers and great team members.

The two following exams, the Acquia Certified Developer - Back-end Specialist, and Front-end Specialist, demonstrate an even deeper grasp of a specialization. Professionals working with Drupal 7 have been testing out successfully as well.

While the current exams are Drupal 7 focused and will continue to be available, we will also have Drupal 8 exams in the coming year.

There is also a new Acquia Certified Drupal Site Builder exam just made available.

Listen to Richard Jones, CTO at i_KOS, talk about his recent experience taking the exam while at DrupalCon Amsterdam, and what it means to him personally, as well as for his business.

Keys to Success: Building Scenario-based Exams

All the Acquia Certification exams are almost entirely scenario based. In this manner, you are testing skills and knowledge instead of just memorization. You are also testing for comprehension in a timely manner, and real world experience is validated through a well constructed and well written scenario-based exam pool.

The scenario for each question is challenging to write, and the test writers draw upon their experiences to do so. The information provided in each scenario is required to answer the related question properly.

To have an exam almost entirely scenario-based is a great accomplishment. We have had an outstanding group of subject-matter experts craft these exam questions based on job task analysis research and they follow sound psychometric best practices.

The latest effort for the Acquia Certified Drupal Site Builder certification exam is no exception.

The Exam Writing Workshop

This month, the Acquia Certified Drupal Site Builder exam was created and the Acquia Certified Developer exam was updated in one combined exam writing workshop. The exam writing workshop is a very intensive and focused effort. The latest effort had a great cross section of the company represented for the workshops, which I facilitated, with Jeff Beeman, Erik Webb, Alex Ward, Adam Malone, Kenny Carlile, and Jonathan Webb serving as Subject Matter Experts.


The exam writers, Subject Matter Experts, are put through a rigorous workshop to write items with supporting documentation. They must agree as a team that each item is relevant, technically accurate and readable.

Several rounds of tech reviews are conducted throughout the workshop and each item must be able to stand up to scrutiny. Test writers have reported that they even dream of test items at night during the course of an intense multi-day workshop, as total immersion to the process is needed to be successful. Team dinners usually end up turning into great debates on something from earlier in the day.

Happy testing!

About Peter

Peter Manijak @PeterManijak: Peter is an experienced Certification and Learning Professional, responsible for creating and managing successful global programs.

Tags:  certification acquia drupal planet cert developers drupal
Catégories: Elsewhere

.VDMi/Blog: Lifting the weight of your website with Kraftwagen

Planet Drupal - mar, 24/02/2015 - 14:33
This blog/tutorial explains how to convert your website to a Drupal profile which can be deployed using Kraftwagen. This will help you create and maintain a professional website and optimize your workflow.What?

Kraftwagen is a drush extension containing a set of Drupal modules enabling you to get a tighter grip on the distribution and subsistence of your (or your customer’s) website.

With Kraftwagen you can easily set up multiple environments like development, staging and production. It also lets you store configuration settings in your code instead of your database saving you a vast amount of time setting up a new environment. This feature enhances the use of version control so every update can be traced or restored.

Another great feature is the ability to maintain third party code like modules and libraries. You tell Kraftwagen which modules you need and it will download and install them for you. New version? No problem, just change the version number.

How does it work?

Your entire website is stored in a profile. Forget Drupal core and the sites folder. This profile contains your custom modules, your theme and configuration settings. So far nothing new on the horizon.

There are three files that make the magic happen:

  • The make file (your_site.make), which defines all the contrib modules and libraries you want to download. Drush handles this, so still no Kraftwagen involved here.
  • The info file (your_site.info), which defines what modules must be enabled. Just a standard Drupal file.
  • In addition to the previous files, Kraftwagen adds the build.make.tpl, which provides a template for your make file. It defines your profile and Kraftwagen directory, which Drupal version you want to use and optionally which patches you want to apply to it. 

If all files are in place and you are satisfied with your configuration, you just give the build command and wait. Drupal core will be installed along with all your modules and settings. When the build is done, all you have to do is give the update command and you’re good to go.

Easy as pie.

How to start?

Visit http://kraftwagen.org/get-started.html and install Kraftwagen. You’ll also find some instructions here on setting up a new project or update an existing project.

But what if you want to convert your existing non-Kraftwagen site to a Drupal profile? That’s what we will be covering in the following paragraphs.

To Kraftwagen and beyond!

First, create a new Kraftwagen folder because we will create a fresh installation of your site. Now, run the drush command drush kw-np (or drush kw-new-project) inside that folder and enter a human name (like Your Site) and machine name (like your_site). You can just press enter when asked for a skeleton and branch.

You’re folder structure should look like this:

kw/
 src/
   cnf/
   modules/
   themes/
   tools/
   translations/
   .gitignore
   README.md
   your_site.info
   your_site.install
   your_site.make
   your_site.profile

We’ve got ourselves an empty Drupal profile here. Time to merge your existing site in here.

Specify your desired Drupal core version in tools/build.make.tpl in this line:

projects[drupal][version] = "7.23"

Congratulations! You’ve just upgraded your site!

Next, copy all your custom modules to modules/custom/. Now, assuming you don’t know all the contrib modules you’ve been using from the top of your head, we will generate a list from your existing site.

Go to the root directory of your existing site and run drush make-generate. Drush generates a make file with all the modules you have installed. Open it and copy this list into your_site.make in your Kraftwagen folder. Notice that there are already some modules prefilled. If you don’t need them, you can erase all modules except the Kraftwagen modules (starting with kw_).

Next up is checking which modules are enabled in your existing site. Again, go the the root of your existing site and run drush pm-list --type=Module --status=enabled.

Unfortunately, this list is not as user friendly as the generated make file. Copy it and paste it into your_site.info in your Kraftwagen folder. Convert every line to:

dependencies[] = modulename

Preferably grouped and sorted by core, contrib, custom and optionally features. You may remove the prefilled dependencies except for the Kraftwagen ones. You’ll notice there are also env_dependencies, these enable the given module only when the defined environment (like development or staging) is set.

Now the modules part is done, copy your theme folder to src/themes/.

As the final part of the setup, navigate to the src directory and run drush kw-s (or drush kw-setup). When you navigate to the parent directory, you’ll find two new folders: builds and cnf.

Every time you make a build, it will be stored in the builds folder. The foldername always matches the date and time of creation, for example: 20150125-135919 (2015-01-25 13:59:19). Every build gets it’s own directory so remember to remove some old builds in a while to save some space.

The cnf folder holds your settings file and files directory. The environment file defines in what kind of environment you’re working, this would be development, staging or production. Open up settings.local.php and set your database info. Also make sure the files directory is writable and has the correct ownership and permissions. The Drupal handbook provides a useful script which handles this for you, you’ll find it at the bottom of this article: https://www.drupal.org/node/244924.

Build it!

Duplicate your database so we don’t overwrite the existing one. Always make a backup of your database before you make a new build.

Navigate to the src directory and run drush kw-b (or drush kw-build). This will download Drupal core and all contrib modules specified in the make file and copy your custom stuff in site/profiles/your_site/.

It also creates symlinks in site/sites/default/ to the settings.php and files folder in your cnf directory. When the build is finished, a symlink build is created to the newly created build in the builds folder so you don’t need to remember the full build name (20150125135919) and to switch easily between build folders if necessary.

So when the build is successful, you can find your profile in an entire Drupal installation in kw/build/.

Adapt your database

Making a build is not enough. We need to tell our database some major stuff is going on in here. Navigate to kw/build/. Normally, drush kw-u (or drush kw-update) would be sufficient. This enables the modules specified in the info file, executes module updates, reverts all features and runs manifests. All in one command.

However, since this is the first time we’ve made a build from a converted website, we need to do some more.

First, we need to tell our database what profile and theme should be used. This can be achieved by executing the following SQL queries:

UPDATE variable SET value = 's:9:"your_site";' WHERE name = 'install_profile'; UPDATE variable SET value = 's:10:"your_theme";' WHERE name = 'theme_default';

Note that the value is a serialized string, so the number in 's:9' should be the character count of 'your_site'. The same goes for 'your_theme'.

Manually clear the cache with:

TRUNCATE `cache`; TRUNCATE `cache_block`; TRUNCATE `cache_bootstrap`; TRUNCATE `cache_field`; TRUNCATE `cache_filter`; TRUNCATE `cache_form`; TRUNCATE `cache_image`; TRUNCATE `cache_menu`; TRUNCATE `cache_page`; TRUNCATE `cache_path`; TRUNCATE `cache_token`; TRUNCATE `cache_update`; TRUNCATE `cache_views`; TRUNCATE `cache_views_data`;

Then we need to update the registry by running drush rr (or drush registry-rebuild). This is necessary because all contrib and custom modules have moved from sites/all/modules/ to profiles/your_site/modules/.

Now, as finishing touch, we can run drush kw-u.

You may need to clear the cache (drush cc all), point your browser to kw/build/ and you’re good to go.

Conclusion

You’ve just turned your website into an easily manageable and deployable Drupal profile.

Need to add a new module? Just add it to your make file and make a new build. Module update? Just change the version number and make a new build. Or do you want to add a staging environment for your customer to check things out? Make a new copy of your Kraftwagen folder (or clone it if you’re using git), change the environment variable to staging and start building.

You should also notice that basically, the contents of kw/src/ folder are copied to site/profiles/your_site/, which means that if you are using git, you can happily code further in the profiles directory.

There are lots of useful things you can do with Kraftwagen. First get comfortable with the build procedure, then you should also check out manifests and the way patches are handled.

For now, as stated in the conclusion at Kraftwagen.org: Enjoy the ride with Kraftwagen...

Catégories: Elsewhere

Cheppers blog: Rebuilding the Cheppers website with Drupal 8: Brave New World

Planet Drupal - mar, 24/02/2015 - 14:01

On February 9, 2015 the Cheppers team decided to start rebuilding the company’s website with Drupal 8. At the time, Drupal 8’s version was Beta 6 with 50+ critical issues, 10+ upgrade path blockers, and it was potentially going to be about a year before the stable version’s release.

Catégories: Elsewhere

Aten Design Group: Fast Content Type UI

Planet Drupal - mar, 24/02/2015 - 13:42

A while ago I made a tool named Sheet2Module, which uses the Config in Code (CINC) module to allow Drupal site builders to make content types and fields directly from Google Spreadsheets. This made a lot of people interested in CINC, but I've found much of that interest was based on a misconception that CINC is focused on spreadsheets. So I recently spent a couple hours making another tool with CINC, to hopefully demonstrate how this is interesting beyond spreadsheets.

Fast Content Type UI is a simple module that lets you edit all your Drupal content types on the same screen. You can't change everything about a content type on that screen, just the things I've found myself adding and editing most often: display name, machine name, and comment status. When that's all you're editing, this is a better, faster UI. And if you need more than that, the standard UI is still there.

And Sheet2Module is also still there. So now you have three very different interfaces for managing your content types in Drupal, or five if you count YAML and PHP as interfaces. The interesting point here isn't really any of these interfaces, it's what these interfaces are hopefully starting to demonstrate: that you can use any interface you want to work with Drupal configuration.

Many of us in the Drupal community spend our days giving clients custom-tailored interfaces to suit their specific needs. Yet when we use Drupal, as administrators, we do our work entirely in the default interfaces. For most of Drupal's history it was a lot of work to create a new interface, because every module managed its configuration in a different way. That's no longer the case. Today it's easy to make your own UI for existing configuration. Fast Content Type UI is one example of that. We should have many more.

Catégories: Elsewhere

InternetDevels: TOP Drupal modules for Views

Planet Drupal - mar, 24/02/2015 - 11:03

We can’t imagine Drupal without Views. It comes in fresh Drupal installation and new modules are being attached to it as the time passes. This additional modules affect the work of Views, extending the functionality and adding new useful features.

Here is a short review of modules that could be combined with Views successfully. If you’d like to get a detailed instruction about the installation of certain module, go to this module’s Drupal.org page and use readme. Hopefully, this article would be useful for you.

Read more
Catégories: Elsewhere

Appnovation Technologies: Demo of a Free Drupal 8 Theme created with LibSass & Gulp

Planet Drupal - mar, 24/02/2015 - 05:45

This post is more of a demo rather than a blog post. I have created a Free Drupal 8 theme called Monoset.

Catégories: Elsewhere

Drupal Easy: DrupalEasy Podcast 145: Route vs. Root vs. Roots (New Tech Cities - Steve Burge)

Planet Drupal - mar, 24/02/2015 - 05:05
Download podcast 145

Steve Burge (steveburge), founder of OSTraining.com joins Andrew, Ted, and Mike to talk about a new blog post series about cities transforming themselves into tech-friendly places with smart investment and forward thinking leaders. We also dive head-first into Drupal.org's content strategy, the evolution of Drupal.org forums, and various ways to pronounce the word "route". Picks of the week includes some free videos, BackDrop on Pantheon, and DrupalCon India.

read more

Catégories: Elsewhere

Drupalize.Me: More Drupal 8 Insights

Planet Drupal - mar, 24/02/2015 - 03:00

Last month, we posted a survey regarding your plans for learning Drupal 8. This was a follow-up to a similar survey we posted back in May, 2014. The responses we received in both instances were remarkably consistent, which is reassuring as we begin to publish our Drupal 8 tutorials. Here are a few big take-aways from our Drupal 8 surveys and some insight into our plans for Drupal 8 tutorials.

Catégories: Elsewhere

Cheeky Monkey Media: Drupal Association Board of Directors - At-Large Position

Planet Drupal - mar, 24/02/2015 - 01:48

This year the Drupal Association Board of Directors has an opening for a single director At-Large position. With this opening, the association reached out to the community to allow anyone to self nominate for the position. As of the closing of the nomination round, there were 24 candidates, from 14 different countries, which I think is an incredible testament to the community.

When I saw this opportunity, I decided to ...Read More

Catégories: Elsewhere

DrupalCon News: Come Discuss the Future of Drupal at Core Conversations

Planet Drupal - mar, 24/02/2015 - 00:42

Core Conversations is a place for people actively working on and contributing to Drupal core to meet, discuss and plan the future of Drupal.

Drupal 8 is very close to having a stable upgrade path, and the number of remaining critical issues is steadily decreasing. The timing of DrupalCon LA means that the focus on talks should be on the future of Drupal, either the short term of 8.1.x, or the future of 8.y.x, or even as far as Drupal 9.

Catégories: Elsewhere

Richard Hartmann: Accuracy

Planet Debian - mar, 24/02/2015 - 00:21

Even if you disregard how amazing this is, this quote blows my proverbial mind:

The test rig is carefully designed to remove any possible sources of error. Even the lapping of waves in the Gulf of Mexico 25 miles away every three to four seconds would have showed up on the sensors, so the apparatus was floated pneumatically to avoid any influence. The apparatus is completely sealed, with power and signals going through liquid metal contacts to prevent any force being transmitted through cables.

Catégories: Elsewhere

Simon Josefsson: Laptop Buying Advice?

Planet Debian - lun, 23/02/2015 - 23:49

My current Lenovo X201 laptop has been with me for over four years. I’ve been looking at new laptop models over the years thinking that I should upgrade. Every time, after checking performance numbers, I’ve always reached the conclusion that it is not worth it. The most performant Intel Broadwell processor is the the Core i7 5600U and it is only about 1.5 times the performance of my current Intel Core i7 620M. Meanwhile disk performance has increased more rapidly, but changing the disk on a laptop is usually simple. Two years ago I upgraded to the Samsung 840 Pro 256GB disk, and this year I swapped that for the Samsung 850 Pro 1TB, and both have been good investments.

Recently my laptop usage patterns have changed slightly, and instead of carrying one laptop around, I have decided to aim for multiple semi-permanent laptops at different locations, coupled with a mobile device that right now is just my phone. The X201 will remain one of my normal work machines.

What remains is to decide on a new laptop, and there begins the fun. My requirements are relatively easy to summarize. The laptop will run a GNU/Linux distribution like Debian, so it has to work well with it. I’ve decided that my preferred CPU is the Intel Core i7 5600U. The screen size, keyboard and mouse is mostly irrelevant as I never work longer periods of time directly on the laptop. Even though the laptop will be semi-permanent, I know there will be times when I take it with me. Thus it has to be as lightweight as possible. If there would be significant advantages in going with a heavier laptop, I might reconsider this, but as far as I can see the only advantage with a heavier machine is bigger/better screen, keyboard (all of which I find irrelevant) and maximum memory capacity (which I would find useful, but not enough of an argument for me). The only sub-1.5kg laptops with the 5600U CPU on the market right now appears to be:

Lenovo X250 1.42kg 12.5″ 1366×768 Lenovo X1 Carbon (3rd gen) 1.44kg 14″ 2560×1440 Dell Latitude E7250 1.25kg 12.5″ 1366×768 Dell XPS 13 1.26kg 13.3″ 3200×1800 HP EliteBook Folio 1040 G2 1.49kg 14″ 1920×1080 HP EliteBook Revolve 810 G3 1.4kg 11.6″ 1366×768

I find it interesting that Lenovo, Dell and HP each have two models that meets my 5600U/sub-1.5kg criteria. Regarding screen, possibly there exists models with other screen resolutions. The XPS 13, HP 810 and X1 models I looked had touch screens, the others did not. As screen is not important to me, I didn’t evaluate this further.

I think all of them would suffice, and there are only subtle differences. All except the XPS 13 can be connected to peripherals using one cable, which I find convenient to avoid a cable mess. All of them have DisplayPort, but HP uses DisplayPort Standard and the rest uses miniDP. The E7250 and X1 have HDMI output. The X250 boosts a 15-pin VGA connector, none of the others have it — I’m not sure if that is a advantage or disadvantage these days. All of them have 2 USB v3.0 ports except the E7250 which has 3 ports. The HP 1040, XPS 13 and X1 Carbon do not have RJ45 Ethernet connectors, which is a significant disadvantage to me. Ironically, only the smallest one of these, the HP 810, can be memory upgraded to 12GB with the others being stuck at 8GB. HP and the E7250 supports NFC, although Debian support is not certain. The E7250 and X250 have a smartcard reader, and again, Debian support is not certain. The X1, X250 and 810 have a 3G/4G card.

Right now, I’m leaning towards rejecting the XPS 13, X1 and HP 1040 because of lack of RJ45 ethernet port. That leaves me with the E7250, X250 and the 810. Of these, the E7250 seems like the winner: lightest, 1 extra USB port, HDMI, NFC, SmartCard-reader. However, it has no 3G/4G-card and no memory upgrade options. Looking for compatibility problems, it seems you have to be careful to not end up with the “Dell Wireless” card and the E7250 appears to come in a docking and non-docking variant but I’m not sure what that means.

Are there other models I should consider? Other thoughts?

Catégories: Elsewhere

Dcycle: Continuous integration with Circle CI and Docker for your Drupal project

Planet Drupal - lun, 23/02/2015 - 22:58

Continuous integration (CI) is the practice of running a series of checks on every push of your code, to make sure it is always in a potentially deployable state; and to make sure you are alerted as soon as possible if it is not.

Continuous integration and Drupal projects

This blog post is aimed at module maintainers, and we'll look at how to use CI for modules hosted on Drupal.org. I'll use as an example a project I'm maintaining, Realistic Dummy Content.

The good news is that Drupal.org has a built-in CI service for hosted modules: to use it, project maintainers need to click on the "Automated Testing" tab of their projects, enable automated testing, and make sure some tests are defined.

Once you have enabled automated testing, every submitted patch will be applied to the code and tested, and the main branches will be tested continually as well.

If you're not sure how to write tests, you can learn by example by looking at the test code of any module which has automated testing enabled.

Limitations of the Drupal.org QA system

The system described above is great, and in this blog post we'll explore how to take it a bit further. Drupal's CI service runs your code on a new Drupal site with Drupal 5.3 enabled. We know this by looking at the log for a test on Realistic Dummy content, which contains:

[13:50:02] Database backend [mysql] loaded. ... [simpletest.db] => [test.php.version] => 5.3 ...

For the sake of this article, let's say we want to use SQLite with php 5.5, and we also want to run checks from the coder project's coder_review module. We can't achieve this within the Drupal.org infrastructure, but it is possible using Docker, CircleCI, and GitHub. Here is how.

Step 1: get a local CoreOS+Docker environment

Let's start by setting up a local development environment on which we can run Docker. Docker is a system which uses Linux containers to run your software and all its dependencies in an isolated environment.

If you need a primer on Docker, check out Getting Started with Docker on Servers for Hackers (March 20, 2014), and A quick intro to Docker for a Drupal project.

Docker works best on CoreOS, which you can install quite easily on any computer using Vagrant and VirtualBox, as explained at Running CoreOS on Vagrant.

Step 2: Add a Dockerfile to your project

Because, in this example, we want to run tests which require changing things on the server, we'll use the Docker container management system to simulate a Ubuntu machine over which we have complete control.

To see how this works, download the latest dev version of realistic_dummy_content to your CoreOS VM, take a look at the included files ./Dockerfile and ./scripts/test.sh to see how they are structured, then run the test script:

./scripts/test.sh

Without any further configuration, you will see tests run on the desired environment: Ubuntu with the correct version of PHP, SQLite, and coder review. (You can also see the results on CircleCI on the project's CI dashbaord if you unfold the "test" section -- we'll see how to set that up for your project later on).

Setting up Docker for your own project is just a question of copy-pasting a few scripts.

Step 3: Make sure there is a mirror of your project on GitHub

Having test results on your command line is nice, but there is no reason to run them yourself. For that we use continuous integration (CI) servers, which run the tests every time someone commits something to your codebase.

Some of you might be familiar with Jenkins, which I use myself and which is great, but for open source projects, there are free CI services out there: the two I know of, CircleCI and Travis CI, synchronize with GitHub, not with Drupal.org, so you need a mirror of your project on GitHub.

Note that it is possible, using the tool HubDrop, to mirror your project on GitHub, but it's not on your account, whereas the CI tools sync only with projects on your own account. My solution has been to add a ./scripts/mirror.sh script to Realistic Dummy Content, and call it once every ten minutes via a Jenkins job on my personal Jenkins server. If you don't have access to a Jenkins server you can also use a cron job on any server to do this.

The mirror of Realistic Dummy Content on GitHub is here.

Step 4: Open a CircleCI account and link it to your GitHub account

As mentioned above, two of the CI tools out there are CircleCI and Travis CI. One of my requirements is that the CI tool integrate well with Docker, because that's my DevOps tool of choice.

As mentioned in Faster Builds with Container-Based Infrastructure and Docker (Mathias Meyer, Travis CI blog, 17 Dec. 2014), it seems that Travis CI is moving towards Docker, but it seems that its new infrastructure is based on Docker, but does not let you run your own Docker containers.

Circle CI, on the other hand, seems to provide more flexibility with regards to Docker, as explained in the article Continuous Integration and Delivery with Docker on CircleCI's website.

Although Travis is a great, widely-used tool (Drush uses it), we'll use CircleCI because I found it easier to set up with Docker.

Once you open a CircleCI account and link it to your GitHub account, you will be able to turn on CI for your mirrored project, in my case Realistic Dummy Content.

Step 5: Add a circle.yml file to your project

In order for Circle CI to know what to do with your project, it needs a circle.yml file at the root of your project. If you look at the circle.yml file at the root Realistic Dummy Content, it is actually quite simple:

machine: services: - docker test: override: - ./scripts/test.sh

That's it! Commit your circle.yml file, and if mirroring with GitHub works correctly, Circle CI will test your build. Debug any errors you may have, and voilà!

Here is the result of a recent Realistic Dummy Content build on CircleCI: unfold the "test" section to see the complete output: PHP version, SQLite database, coder review...

Conclusion

We have seen how you can easily add Docker support to make sure the tests and checks you run on your code are in a controlled environment, with the extensions you need (one could imagine a module which requires some external system like ApacheSolr installed on the server -- Docker allows this too). This is one concrete application of DevOps: reducing the risk of glitches where "tests pass on my dev machine but not on my CI server".

Tags: planetblog
Catégories: Elsewhere

tombola: Making a Drupal Distribution #1

Planet Drupal - lun, 23/02/2015 - 17:59

Recreating and simplifying a multiple site platform by creating a re-usable distribution.

#1 Getting started.

Catégories: Elsewhere

valechatech: Hack Proof your drupal site

Planet Drupal - lun, 23/02/2015 - 15:51

Security of the Drupal website is a important stuff for the site owners, site developers.This blog post has my presentation at the Drupal Camp Mumbai that  intended for Drupalers who want to avoid security loop holes while writing code or architecting solutions. We delved into common security issues that ails custom code and has both vulnerable and secure code snippets.This is mostly about my encounters and experience after doing 50+ project application reviews and also a good guideline for new contributors.



Hack Proof Your Drupal Site from Naveen Valecha


Next article:  A guide to review Project Applications.
Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur - Elsewhere