Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 56 min 4 sec

Chapter Three: Drupal 8 Automated Testing with Travis CI

jeu, 14/05/2015 - 19:05

Travis CI burst onto the hosted continous integration scene by offering free testing for public projects. If your code is on Github and available to the public then Travis will run your tests for you.



I will show you how to get Drupal 8 running all of it's PHPunit tests in Travis. If you want to use Travis for your own private repo, you will have to pay a little bit. In my opinion that is a small price to pay for never setting up Jenkins again.



First we specify our programming language and the version.




language: php

php:
- 5.4


Next up we specify our database information. Note that we do not have to specify install steps for either PHP or MySQL.

Catégories: Elsewhere

Forum One: Zero to MVP in 40 Minutes: What We learned Building Headless Drupal 8 for DrupalCon LA

jeu, 14/05/2015 - 18:51

My colleague Adam Juran and I just finished with our session, Zero to MVP in 40 minutes: Coder and Themer Get Rich Quick in Silicon Valley, at DrupalCon LA. This one was a real journey to prepare, and through it we learned a lot of dirty truths about Drupal 8, Javascript frameworks, and the use cases where the two make sense together.

The live coding challenge in our session proposal seemed simple: create a web application that ingests content from an external API, performs content management tasks (data modelling, relationships, etc.) through the Drupal 8 interface, and deliver it all to an AngularJS front-end. This is exactly the “headless Drupal” stuff that everyone has been so excited about for the last year, so doing it in a 40 minute head-to-head code battle seemed like an entertaining session.

Ingesting content from an external API

The first hard truth we discovered was the limitations of the still-nascent Drupal 8. Every monthly release of a new Drupal 8 beta includes a series of “change records,” defining all the system-wide changes that will have to be accounted for everywhere else. For example, one change record notes that a variable we often use in Drupal forms is now a different kind of object. This change breaks every single form, everywhere in Drupal.

The frequency of this kind of change record is a problem for anyone who tries to maintain a contributed module. No one can keep up with their code breaking every month, so most don’t. The module works when they publish it as “stable”, but two or three months later, it’s fundamentally broken. changes like this currently happen 10-15 times every month. Any module we were hoping to use as a part of this requirement – Twitter, Oauth, Facebook – were broken when we started testing.

We finally settled on using Drupal’s robust Migrate module to bring in external content. After all, Drupal 7 Migrate can import content from almost any format! Turns out that this isn’t the case with Drupal 8 core’s Migrate module. It’s limited to the basic framework you need for all migrations. Importers for various file types and sources simply haven’t been written yet.

No matter which direction we turned, we were faced with the fact that Drupal 8 needed work to perform the first requirement in our challenge. We chose to create a CSV Source plugin ourselves (with much help from mikeryan and chx) just to be able to meet this requirement. This was not something we could show in the presentation; it was only a prerequisite. Phew!

Displaying it All in Angular

Building an AngularJS based front end for this presentation involved making decisions about architecture, which ended up as the critical focus of our talk. AngularJS is a complete framework, which normally handles the entire application: data ingestion, manipulation, and display. Why would you stick Drupal in there? And what would an Angular application look like architecturally, with Drupal 8 inside?

You always have a choice of what to do and where to do it. Either system can ingest data, and either system can do data manipulation. Your decision should be based on which tool does each job the best, in your particular use case: a catch-all phrase that includes factors like scalability and depth of functionality, but also subtler elements like the expertise of your team. If you have a shop full of AngularJS people and a simple use case, you should probably build the entire app in Angular!

Given that perspective, Drupal really stands out as a data ingestion and processing engine. Even when you have to write a new Migration source plugin, the Entity model, Drupal’s “plug-ability”, and Views make data crunching extremely easy. This is a strong contrast to data work in Angular, where you have to write everything from scratch.

We feel that the best combination of Drupal and Angular is with Drupal ingesting content, manipulating it, and spitting it out in a ready-to-go format for AngularJS to consume. This limits the Angular application to its strengths: layout, with data from a REST back-end, and only simple logic.

The Session

In the session, we talked a bit about the larger concepts involved, and moved fairly quickly into the technical demonstration. First, Adam demonstrated the flexibility of the decoupled front-end, using bower libraries to build an attractive layout without writing a single line of custom CSS.  Then I demonstrated importing data from CSV sources into Drupal 8, along with the simplicity of configuring Drupal Views to output JSON. Taken together, the videos are 37 minutes long – not bad for a totally custom RESTful endpoint and a nice looking front-end!

Here is Adam’s screencast, showing off the power of the bootstrap-material-design library to build a good looking site without any custom CSS at all:


http://forumone.com/wp-content/uploads/2015/05/cvst-theming.m4v

Here is my screencast, demonstrating how easy it is to create Migrate module importers and REST exports in Drupal 8.

And here is the final screencast, quickly showing the changes we made in AngularJS to have it call the two Drupal Services.

Want to learn of Forum One’s Drupal development secrets? Check out our other Drupalcon blog posts, or visit our booth (#107) and talk with our tech wizards in person!

Catégories: Elsewhere

Another Drop in the Drupal Sea: DrupalCon LA Wednesday Recap

jeu, 14/05/2015 - 18:30

After the keynote I took advantage of the opportunity to meet face to face with a new contact. Then, after lunch I headed into a couple of BOFs that were way out of my league and made my brain hurt. I finished up the day with a session that was more in my comfort zone.

I think it's good to stretch my mind and get out of my comfort zone even though it, quite honestly, left me feeling really stupid. I also felt really tired by the end of the day. So, I decided to take a pass on any social events for the evening and just relax in my hotel room.

read more

Catégories: Elsewhere

InternetDevels: DrupalTour Zhytomyr

jeu, 14/05/2015 - 15:52

Spring time is just perfect for Drupal rides! The weather is great, drupallers are in the good mood and Drupal-van shines in the bright sun… So we decided to make a ride to Zhytomyr. And it turned out to be awesome!

We had to leave Lutsk at 7:30 AM to arrive to Zhytomyr in time. Getting up at 6 on Saturday morning is not so easy, by the way! But we actually had no other options and the trip to Zhytomyr was worth it :)

Read more
Catégories: Elsewhere

Friendly Machine: Notes from DrupalCon Los Angeles

jeu, 14/05/2015 - 15:41

On Tuesday, Dries gave the best keynote I’ve heard him deliver. It included some very interesting Drupal history and it brought home to me how extraordinary Drupal really is. There were so many points in the project’s history when things could have happened differently - or not happened at all. To see a photo of the first DrupalCon attendees 10 years ago (27 people) while sitting among ~3000 Drupalists from around the world was pretty amazing.

There are so many people doing big, interesting things with Drupal. Despite concerns about corporate influence within the Drupal community, the project empowers a huge number of non-profits and institutions of higher education and it was great to see them so well represented here. It might be weird to talk about software as a force for good, but that’s really how I see Drupal. It makes a huge difference to a lot of organizations and the valuable work they contribute to society.

As you may have heard, there will be a DrupalCon in India next year. The city hasn’t been announced yet, but my money is on Mumbai. I’ve known two people who have traveled to India. Both said it was amazing and intense. I’m not sure if I’ll go, but I’m very tempted. I love travel, but that is one hell of a long flight (20 hours).

The sessions this year were all recorded and put on YouTube, so if you want to catch up on anything you might have missed, here’s the link. There are a few sessions I recommend you check out:

However, the biggest benefit of DrupalCon for me isn’t the sessions. It’s getting to meet people and talking with them about their projects and how they are solving the problems they encounter. To everyone that came by the Lullabot booth to chat, thank you! It was great to see you in person and I hope to chat again next year - if not sooner!

Drupal
Catégories: Elsewhere

Acquia: Build Your Drupal 8 Team: Technical Roles and Required Skills

jeu, 14/05/2015 - 15:38

Last time, we discussed some big themes your Drupal 8 team should be synched up with, like object-oriented programming. Now we're going to drill down into more specifics on the technical side.

Is your tech team full of generalists, or do all your developers have special skill sets and focus on specific kinds of functionality, like databases or communications? Either way, someone on your team will have to fill each of these technical roles for a successful Drupal 8 project.

Drupal 8 Architect

More than anyone else on the project, the Drupal 8 architect needs to understand Drupal 8 in depth. The architect needs to make the decisions about the project's overall architecture, which requires envisioning how the system works as a whole. This is bigger than just the Drupal 8 application, because the project needs to fit into your company's entire software environment. It may need to be integrated with other corporate back-end systems, so this role needs to understand the full technical environment, not just the tech stack that comes with Drupal 8. As much as possible, this individual needs to have a strong understanding of front-end and back-end development tools in addition to a thorough understanding of how Drupal 8 works.

UI Designer

The UI designer needs to understand what the technology is capable of and how to use it to create the best experience for end users. To work with Drupal 8, the UI designer should keep building HTML, CSS and Javascript knowledge, but also develop a Drupal 8-specific understanding of how to create themes and build sites. Learning the capabilities of Twig is needed because Twig replaces PHPTemplate in the new version of Drupal. Instead of .tpl.php files, .html.twig files are needed.

Front-End Developer

All that stuff the UI designer promised the business? It's the front-end developer's job to turn that hypothetical design into a functioning interface. Like the UI designer, front end developers should enhance their knowledge of HTML, CSS and Javascript, and pick up knowledge of Twig. PHP knowledge will help also; so will knowing MySQL. The front-end developer will also want a Drupal 8-specific understanding of how to create themes and build sites, as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Back-End Developer

Clicking on website front-end elements does nothing until you implement the functionality in the back-end. You need to be able to write new functionality from scratch, building on existing components when possible. When the application needs to integrate with other systems, the back-end developer writes the code that hooks it all together into a system that functions seamlessly. This role needs some knowledge of front-end tools like HTML, CSS and JavaScript, but it also requires understanding back-end tools like PHP and MySQL in depth. For Drupal 8 knowledge, the back-end developer should focus on architecture and planning topics as well as how to develop custom modules and address Drupal 8 performance and Drupal 8 security concerns.

Marketing Technical Lead

The marketing technical lead owns the content publishing process. She defines the procedure for publishing content and makes sure it adheres to site standards. Because content doesn't accomplish anything unless someone sees it, the marketing technical lead needs to make sure it follows good SEO and SEM practices. It's important that the marketing tech lead keeps current with ever-changing SEO practices, and focuses on learning Drupal 8 as a content management system. Learning about the administration functions, and the kinds of changes you can make that won't require a developer to write code, will be especially useful for this role.

Next time: Non-Technical Team Roles and Required Skills for a Drupal 8 Project.

Tags:  acquia drupal planet
Catégories: Elsewhere

Drupalize.Me: Learning To Debug: Stop Thinking and Look

jeu, 14/05/2015 - 15:02

Debugging is a discipline that requires patience, and a fervent attention to detail. In the often times fast paced world of software development, when we're faced with deadlines, and an ever growing list of new features to add, and bugs to resolve, it can be a difficult to slow down and proceed in a meticulous, measured fashion. When it comes to solving difficult problems though, this fastidious approach is exactly what's required to locate, and resolve, a problem's root cause.

Catégories: Elsewhere

Annertech: Thoughts on DrupalCon LA's Front End Forum

jeu, 14/05/2015 - 13:34
Thoughts on DrupalCon LA's Front End Forum

At DrupalconLA, I had the opportunity to go to an Open Front End Forum, wherein people chatted about the state of the front end. It was good fun, and the moderator did a good job of keeping the conversation flowing.

First question: "Where is the line that separates front end from back end?"

There was some disagreement on that. There is a line, there is no line, it's a permeable line... Going on to explore what defined front end or backend, people cited tasks and tools like PHP, HTML/CSS/JS, the browser, Photoshop, in favour of one argument or another.

Catégories: Elsewhere

Trellon.com: Agile Design Techniques - Video Is Live

jeu, 14/05/2015 - 02:47

Trellon presented a session about Agile design techniques at Drupalcon Los Angeles which was very well received. Over 100 people were in attendance to hear Blake Maples, Mike Haggerty and Jake Tooman talk about the way we introduced Agile design within Trellon and made it work for the groups we serve.

Slides from the presentation are available at the following URL:

https://docs.google.com/presentation/d/1XwXELD7pIQ8CQUuNCv00hxaavUWeaKBj...

Catégories: Elsewhere

Pixelite: Drupal Migrate D2D :: Taxonomy terms on nodes

jeu, 14/05/2015 - 02:00

A migration project I am currently working on hit a small hurdle with taxonomy terms on a content type. This took too long to resolve. Hopefully posting this here will save others the time and hassle I went though.

Migrate D2D

I am going to assume that if you are reading this you are already using the migrate_d2d module so I won’t go into the big explanation about what it is, why you should use it and just how greatful we all should be to Mike Ryan.

Node migration and taxonomies

After following the docs I found that my taxonomy field was not being populated. A little digging led me to the conclusion that this was not something d2d handled out of the box and it was something I would have to deal with myself. There are a number of moving parts involved with this and due to all of these I can understand why it is not something migrate d2d could do.

public function prepare($entity, $row)

The magic happens here. The prepare() function is the final thing to be called before the node object is saved. This is where we get to do any final tweaks or tidyups. You can find full detail on this in the Commonly implemented Migration methods page in the Migrate handbook.

In the prepare() function the $entity is the new object that we are about to save and the $row is our source object. At this point the taxonomy has been added to the $row.

Within the $row object the taxonomy has been added with its vid as the root level attribute. If you don’t know to watch for that it can catch you. Added to that it is the vid of the destination vocabulary that is used which caught me off guard. The situation I had did not have me migrating the vobacularies, just the terms within them and the vid for the Categories vocab was not the same on my development environment as it was on my staging environment. This caught me out initially as I don’t have direct access to the staging database to examine the content of tables.

source $row->{destination vid} = array({source tid}, {source tid}, {source tid})

Once it was realised that the vid was from the destination vocabulary things got easier. This is how the code looked in the end for me;

<?php public function prepare($node, $row) { // The node's terms are in an array under their destination vocab ID and // this is different from environment to environment. However, we've only // got one taxonomy... $keys = array_keys((array) $row); foreach ($keys as $key) { if (is_numeric($key)) { $cat_vid = $key; break; } } if (!empty($row->{$cat_vid})) { foreach ($row->{$cat_vid} as $tid) { // We want the tid of the term we have migrated. This lets us look it up // our migrate_map table. $new_tid = db_select('migrate_map_tncategoryterms', 'm') ->fields('m', array('destid1')) ->condition('sourceid1', $tid) ->execute() ->fetchField(); $node->field_category[LANGUAGE_NONE][]['tid'] = $new_tid; } } } ?> Caveats

This worked for me because I only had one taxonomy field to worry about. The moment you get more than one you will want to revisit the assignment of $new_tid to the appropriate field. This shouldn’t be a problem to hand code and if you have migrated the vocabularies too you may be able to use the migrate_map table to make something more dynamic.

Comments

If you have (or are currently) using migrate I would be interested to hear how you found it. Especially if you are migrating terms, but not the vocabulary.

Catégories: Elsewhere

Midwestern Mac, LLC: Ansible for Drupal infrastructure and deployments - DrupalCon LA 2015 BoF

mer, 13/05/2015 - 23:57

We had a great discussion about how different companies and individuals are using Ansible for Drupal infrastructure management and deployments at DrupalCon LA, and I wanted to post some slides from my (short) intro to Ansible presentation here, as well as a few notes from the presentation.

The slides are below:

Notes from the BoF

If first gave an overview of the basics of Ansible, demonstrating some Ad-Hoc commands on my Raspberry Pi Dramble (a cluster of six Raspberry Pi 2 computers running Drupal 8), then we dove headfirst into a great conversation about Ansible and Drupal.

Catégories: Elsewhere

Drupal Easy: DrupalEasy Podcast 152: DrupalCon Los Angeles - Day 1 Recap

mer, 13/05/2015 - 22:20
Download Podcast 152

Live (almost) from Los Angeles, Ryan, Ted, and Mike are joined by a few familiar voices for a quick recap of day 1 of DrupalCon. We talk highlights, songs from the prenote, special Drupal moments, and Ryan interviews Rob Loach from Kalamuna about Kalabox 2.0.

read more

Catégories: Elsewhere

Another Drop in the Drupal Sea: DrupalCon LA Tuesday Recap

mer, 13/05/2015 - 18:26

I followed my own advice from my DrupalCon for n00bs post, and took part in some great sessions, checked out a BOF, ran a BOF of my own and hung out a bit in the Exhibition Hall. I loved finding out about Symfony and Drupal 8 and am super excited about what the combination has to offer. I was pleasantly surprised by the attendance in my BOF. And, I picked up some great swag in the Exhibition Hall and had some nice conversations.

Let's just hope that they get the lunch situation sorted out better today!

read more

Catégories: Elsewhere

Microserve: DrupalCamp Bristol 2015 - Speakers and Sponsors needed!

mer, 13/05/2015 - 18:24

We're proud to say DrupalCamp Bristol 2015 is taking shape nicely; tickets are selling well, sessions are being submitted and we already have a number of Sponsors on board!

With just under 2 months to go we're now keen to get more sessions submitted and the remaining Sponsor spaces filled up. If you wish to propose a session for the Business day on Friday 3rd July then please get in touch with Rick Donohoe - rick@drupalcampbristol.co.uk. If you wish to submit a session for the Saturday conference day then please use the form on the website to submit your idea.

Looking to Sponsor the event? Get in touch here.

Lastly, thanks to everyone who has purchased a ticket so far and a big thanks to all the committee members for their hard work to date.

Rick Donohoe
Catégories: Elsewhere

Vardot: The Drupal Ecosystem: How to Productize Your Drupal Services

mer, 13/05/2015 - 13:40
Resources

As a web development firm scales, it will inevitably run into a complicated dilemma: whether or not to productize its services. Particularly with a complex and labor intensive content management system like Drupal, turning away from a business model built around providing specialized service to each individual client becomes increasingly logical as a web development firm expands and builds a reputation.

But, as you may have already noted, this comes at a cost—productizing your Drupal services means that each client ostensibly receives less individual attention from its web vendor. However, if done correctly, productizing your Drupal services will not only improve a web development firm's services, but will streamline the design and development process and insure that clients consistently receive excellent customer service, support, and, ultimately, superior web products.

So contemplating productizing your Drupal services doesn't need to run hand in hand with your company having an existential crisis. Here's why:

Productizing your web services means that you'll only need to develop a platform once, instead of starting from scratch each time you take on a project. It also means that a development firm only needs to maintain one system instead of several, which allows software engineers and customer support managers to focus all their energy on that particular system, and thereby improving overall experience for all of a firm's clients collectively.

So in short, what does productizing your web development services achieve? It reduces the total cost of ownership; reduces operational costs for the vendor; makes higher quality standards easier to attain; and finally, delivers a dependably high-quality product to clients. 

Check out this presentation assembled by Vardot's CEO, Mohammed Razem, that outlines the product vs. service debate by breaking down the phases of developing a website using Drupal. It details how consolidating these practices into a streamlined product will provide a more refined development and implementation process and will allow a team to produce more consistent products by cutting down on the unnecessary and time-consuming aspects associated with a service-focused model, and how that will result in better overall results.

Dig in: 

http://www.slideshare.net/doublethink/the-drupal-ecosystem-for-drupal-services

 

Tags:  Productize Drupal Drupal Services Drupal Planet Title:  The Drupal Ecosystem: How to Productize Your Drupal Services
Catégories: Elsewhere

Midwestern Mac, LLC: Thoughts on the Acquia Certified Drupal Site Builder Exam

mer, 13/05/2015 - 07:16

After taking the trifecta of Acquia Developer Certification (General, Back-end, Front-end) exams and earned a new black 'Grand Master' sticker, I decided to complete the gauntlet and take the Acquia Certified Drupal Site Builder Exam at DrupalCon LA.

Catégories: Elsewhere

ThinkDrop Consulting: Continuous Deployment, Integration, Testing & Delivery with Open DevShop

mer, 13/05/2015 - 01:34

Well before "DevOps" was a thing, and long before DevShop existed, was "CI". Continuous Integration is a critical part of successful software development.  As a web CMS, Drupal has lagged a bit behind in joining up with this world of CI.

One of the reasons that we don't see CI being used as much as we'd like is that it is hard to setup, and even harder to maintain long term.  Wiring up your version control systems to your servers and running tests on a continual basis takes some serious knowledge and experience. There are a lot of tools to try and make it easier, like Jenkins, but there is still a lot of setup and jerry-rigging needed to make everything flow smoothly from git push to test runs to QA analysis and acceptance.

Setup is one thing, keeping things running smoothly is another entirely. With a home-spun continuous integration system, the system operators are usually the only ones who know how it works. This can become a real challenge as people move to new jobs or have other responsibilities.

This is one of the reasons why we created DevShop: to make it ridiculously easy to setup and keep up a CI environment. DevShop's mission is to have everything you need out of the box, with as little setup, or at least as simple a setup process as possible.

Continuous Deployment

DevShop has always had Continuous Deployment: When a developer pushes code to the version control repository, it is deployed to any environment configured to follow that branch.  This is usually done on the main development branch, typically called master, and the environment is typically been called dev.

However for the last few years, DevShop has had the ability to host unlimited "branch environments".  This means that individual developers can work on their code on separate branches, and each one can get it's own copy of the site up and running on that branch.  This reduces the chances for conflicts between multiple developers and helps reduce the time needed to debug problems in the code because if you find a problem, you know what branch it came from.  

We've found that having branch environments is a much more productive way to code than a shared dev environment on the master branch.

Pull Request Environments

DevShop has been able to react to GitHub Pull Requests by creating a new environment since last year.  Each project can be configured to either clone an environment or run a fresh install every time a Pull Request is created. It will even tear down the environment when the Pull Request is closed.

Developers have less management to do using Pull Request environments: They don't need access to DevShop at all.  Everything is fully automated.

This method is even better than setting up branch environments, since Pull Requests are more than just code: anyone on the team can comment on every Pull Request, offering advice or asking questions about the proposed code.  Users can even comment on individual lines of code, making the peer review process smoother than ever by letting teams communicate directly on the code..

Continuous Testing

Recently we've added built-in behat testing to DevShop: When a "Test" task is triggered, the logs are saved to the server and displayed to users through the web interface in real time.   The pass or fail result is then displayed in the environment user interface as green or red, respectively, along with the full test results with each step highlighted with Pass, Fail, or Skipped.

This gives developers instant feedback on the state of their code, and, because it is running in an online environment, others can review the site and the test results along with them.  

The future of DevShop testing is to incorporate even more tests, like PHPUnit, CodeSniffer, and PHP Mess Detectors.  Having a common interface for all of these tests will help teams detect problems early and efficiently.

Continuous Integration

Continuous Integration can mean different things to different people.  In this context I am referring to the full integration of version control, environments, tests, and notifications to users.  By tying all of these things together, you can close the feedback look and accelerate software development dramatically.

GitHub, the most popular git host in the world, got to be that way in part by providing an extremely robust API that can be used to setup continuous integration systems. Each repository can have "Post commit receive" webhooks setup that will notify various systems that new code is available.

The "Deployments" API" allows your systems to notify github (and other systems) that code was deployed to certain environments.  The "Commit Status" API can be used to flag individual commits with a Pass, Fail, or Pending status.  This shows up in the web interface as a a green check, a red X, or an orange circle both on the commit and on each open Pull Request in the repository.  A failing commit will notify developers that they should "Merge with Caution", making it much less likely that code reviewers will merge bad code.

DevShop now leverages both the Deployments and the Commit status APIs for Pull Request environments.

Deployments are listed right in line with the commit logs of a pull request, and give the team direct links to the environments created by devshop.

Commit Statuses display not only a pass or fail status, but also link directy to test results, giving developers the instant feedback needed to respond quickly to issues.

Continuous Notification

An important part of any CI system is the notifications.  Without them, developers and their teams don't know that there is anything for them to do. GitHub has great integration with just about any chat service, and now so does DevShop.  

When your CI system is integrated with a chat service, the entire team gets visibility into the progress and status of the project.  New commits pushed notify others that there is new work to pull, and test notifications alert everyone to the passing or failing of those code pushes. Having immediate feedback on these types of things in crucial for maintaining a speedy development pace.

Continuous Delivery

With all of the pieces in place, you can start to think about Continuous Delivery.  Continuous Delivery is the act of "going live" with your code on a continuous basis, or at least very often.

DevShop allows your live environment to track a branch or a tag.  If tracking a tag, you must manually go in and deploy a new tag when you are ready to release your code.

If tracking a branch, however, your code will deploy as soon as it is pushed to that branch.  Deploy hooks ensure all of the appropriate things run after the code drop, such as update.php and cache clearing.  This is what makes continuous delivery possible.

If using Pull Requests for development, you can use GitHub's Merge button to deploy to live if you setup your production environment to track your main branch.  With the Commit Status and Deployment APIs, you can be sure that not only did the tests pass but the site looks good with the new code.

Merging to deploy to live is a great way to work.  You no longer need to access devshop to deploy a new tagged release, and you no longer need to manually merge code, hoping that everything works.

If it's green, it's working.  If your tests are robust enough, you can guarantee that the new code works.

If your tests are so complete that you start to reach 100% code coverage, you can start thinking about true continuous delivery: Tests Pass? Automatically merge to live and deploy.  This requires that your tests are amazing and reliable, but it is possible.

DevShop doesn't have the ability out of the box to setup true continuous delivery, but it would not take too much work.  You could use the hosting task status hook to fire off a merge using GitHub's API.

As more people start to use Continuous Delivery, we can work on incorporating that into the devshop process.

All wrapped up in a Bow

With DevShop, you will spend (much) less time on your support systems so you can focus on your websites.  We hope to continue to find ways to improve the development process and incorporate them directly into the platform.

We encourage everyone to embrace continuous integration principles on their projects, whether it is using DevShop or not.  Not only does efficiency go up, but code quality and morale does too.  

If you are a software developer, having tests in place will change your life. Everyone involved in the project, from clients to quality assurance folks to the dev team, will sleep better at night.

Tags: devshopcontinuous integrationPlanet Drupal
Catégories: Elsewhere

Drupal core announcements: Drupal 8 beta 11 on Wednesday, May 27, 2015

mer, 13/05/2015 - 00:56

The next beta release for Drupal 8 will be beta 11! (Read more about beta releases.) The beta is scheduled for Wednesday, May 27, 2015.

To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on May 27.

Catégories: Elsewhere

Amazee Labs: DrupalCon Los Angeles - Day 1: Dawn of the Drupalistas

mar, 12/05/2015 - 20:15
DrupalCon Los Angeles - Day 1: Dawn of the Drupalistas

Yesterday, just shortly after the sun sprung up and sparked southern California’s beautiful coastal lines, the doors of LA’s Convention Center opened. Welcoming with it, a first wave of eager Drupalistas and surrounding them by its air conditioned walls. And for the subsequent days that are surely to follow, it will continue to receive and house those, transforming it, to the home of DrupalCon 2015.

To some of us, this day began just like two previous iterations in the past, with the Drupal 8 Training for Drupalistas. And like the preceding ones before, the turn out was again, lovely. A fresh batch of new ambitious students took their seats and embarked on a cinematic journey, led by our resident training director, Diana Montalion.

From lively exchanges of know-how, to focused, almost silent moments, the classroom experienced a day of captivating performances. And in-between those, pupils were given hourly breaks to take a breath and pick from a variety of delicious beverages (there were cookies!) and the oh so essential, mandatory coffee.

After a wholesome feast around noon-ish, the reins were passed on to Jason, who expertly guided the keen students through the inner workings of Drupal 8’s translation system. Shortly thereafter, Kathryn took over to introduce them to the beautiful side of Drupal 8 (theming!) before finally ending again within Diana’s experienced hands.

Meanwhile, the lower floor saw a much more handy development: the exhibition hall of large, empty at first, but slowly building up to a small but respectable miniature city of brands. Replacing muffled sounds of classroom keyboards with the repeating cracks of rising booths, only to be broken apart by the occasional clash of shouty staff members.

Thus the day drew to an end, and our students were being led on their way, charged with knowledge and filled with cookies. The building emptied its walls again to prepare for tomorrow, when at dawn, the drupalistas will rise again.

Catégories: Elsewhere

Jim Birch: Dude, Where are my Templates? Using the Drupal 7 Theme Developer to find the way.

mar, 12/05/2015 - 19:11

The first line of the description of the Drupal Theme Developer Module says that it is "Firebug for Drupal themeing".  I couldn't agree more.  This is the ultimate tool when you need to find out which theme hook, or which template file to modify based on your design and layout needs.

It is a finicky module though, it doesn't work with the latest version of one of it's dependencies, simplehtmldom API, and when turned on it can break your layout. 

Note that this module injects markers into the DOM to do its magic. This may cause some themes to behave erratically and less capable browsers may make it worse (especially IE)/. Enable it when needed, and disable it afterwards.

To ensure I install the correct branch of the modules, and to speed up enabling and disabling, I set up some aliases in my local/development computer's .bash_profile:

Read more

Catégories: Elsewhere

Pages