You ever have those really good ideas, create a product or website around it, and no one cares?  That is what is happening with the Custom Tab at Assembla.  It’s about my favorite tool in the stack there, since I can use it to extend Assembla functionality and tools without doing anything.  

Our team used to have a bunch of tools all over the place, New Relic for monitoring our application, Nagios for monitoring our servers, Jenkins for our CI, Kibana for log aggregation, and even a custom application for showing off our Developer stats.  We had documentation to let everyone know where each tool was.  It was tedious and annoying to keep up to date and inform everyone where to go next.

Instead, I put them in Custom Tabs:

Now, when we add a new tool to our stack, its immediately available and visible for all our developers to use from within the Assembla project.

Ideally you are able to use authentication integration so that being logged into Assembla also has you logged into the other service or tool removing the need to double login, but typically this is not an issue as you would have to login again for another browser tab.

We also just added the favicon as default to Custom Tab tabs, I hope you enjoy this feature as much as me. To try this out yourself, visit the Admin tab of your project > click on Tools > and Add the Custom Tab Tool. 

To Check Out More Cool Features and Tools - www.assembla.com

I just finished up a webinar entitled Production Monitoring: The Key Steps Towards Continuous Delivery, presented with Airbrake.io The webinar focused on how Production Monitoring is the most important process in any application, but particularly online applications when practicing Continuous Delivery.

The Key Points were:

• Continuous Delivery is not a process that I can define for you, rather its a goal.
• The Goal of being able to continuously deliver your code to QA/UAT or Production and react in real time to the results of the release.
• Iteration Planning is Stressful
• Confidence in Releases is Key to Automating Deploys
• Confidence in Code is Key to Moving Fast
• More Data and Less Stress

If you missed the webinar, you can view it above or watch it on youtube and/or download the slides.

At the end of the webinar, I was left wondering: How does Assembla fit into the Continuous Delivery Pipeline? Stay tuned, more to come.

To Learn More about Continuous Delivery checkout some of my other blog postings:

Continuous Delivery vs Continuous Deployment vs Continuous Integration 

Distributed Continuous Integration - Keep the Mainline Clean 

Avoiding Premature Integration or: How we learned to stop worrying and ship software every day

Michael posted last week about A Developer Dashboard for All Your Tools.   He showed how you can use custom tabs to display external Web pages in your Assembla space.  This is a cheap trick with powerful effects on focusing attention. In this article we will explain how to set up a custom tab.

Setup

Go to your Admin tab and select "Tools".  You will find the following panel:

Click on the button to add a new tab to the top of your space.  Select the new tab.  You will see a form where you can configure it.

Now, sort your tab into the position that you want.  You can go back to the Admin tab and select Appearance.  You will see a Navigation panel where you can drag your tabs into the order you want.

Examples

I get a management report with key financial numbers on a Google spreadsheet. After moving it to a custom tab, I look at it more frequently.

As you can see below, we put Jenkins in a custom tab, and we used our Jenkins oAuth plugin to log viewers into Jenkins with their Assembla accounts.

We keep a lot of monitoring tools in our tab bar:

How do you plan, manage and close Scrum sprints with Assembla?

Stabilize a Scrumban iteration? (And what is "Scrumban"?)

Manage the tasks in a Kanban or lean Continuous Delivery process?

Assembla has very flexible tools for managing Agile (and non-Agile) development processes. So flexible, that it's not always obvious how to manage tasks for a specific Agile methodology.

That's why we have created three online tutorials that walk you through how to manage Scrum, Scrumban and Kanban processes using Assembla's new Renzoku feature set.

You can find the tutorials here:

How to Manage Scrum with Assembla

How to Manage Scrumban with Assembla

How to Manage Kanban/Continuous with Assembla

By the way, Scrumban uses periodic releases, like Scrum, but adopts some lean practices from Kanban. Read about it here.

How do you see the forest but keep teams focused on their own trees? With Space Manager.

Assembla recently introduced the Space Manager feature to help service providers and companies with large projects handle two use cases:

• Many client projects being serviced by one or a small number of development teams.

• One complex project being developed by several development teams.

Space Manager, along with the new Tag feature, can help these companies manage their backlog better, let teams focus on their own work, and give clients and customers a restricted view of their own ticket lists but nobody else’s. It helps managers manage the “big picture” while making teams more efficient.

Use Case #1: Many projects served by one team

What if you are a service provider or custom development firm creating software apps for multiple clients? Or part of a corporate web site or application group serving multiple internal customers?

Then you want to maintain a master backlog of tasks, but also keep track of which tasks belong to which clients. You may also want to let your clients submit requests directly to the master backlog, and later view the progress of those tickets, but not be able to see tickets submitted by anyone else.

With Space Manager, you can set up a “Master Space” for the entire development team, then a series of “Child Spaces,” one for each client. The process will then work as shown in the diagram below.

As clients submit tickets, the tickets are tagged with the child space name of each client (in the diagram, “C1,” “C2” and “C3).

The space owner and designated tech leads have visibility into a master backlog of all submitted tickets. They validate and refine the tickets, then sort them in order of priority, taking account of the importance of the individual tickets and the need to balance the demands of the clients.

They then select the most important tasks to go into the “Current” milestone (or the current Scrum sprint, or the Kanban process).

The development team can see all of the tickets in the Milestone, Planner and Cardwall views, sorted by priority, and tagged by the client.

If you want to give clients visibility into their tickets you can do so, but they are restricted to the tickets in their own child space - they can’t see tickets (or messages, or repositories) from any other child space. 

Use Case #2: One project developed by many teams

What if you are working on a large project that is being created by many teams - perhaps an architecture team, a UI team, and a backend team?

Then you want to maintain a master backlog of tasks, but let each team keep track of its own tickets, documents and code, without having to sort through the work of the other teams.

With Space Manager, you can set up a “Master Space” for the complete project, then a series of “Child Spaces,” one for each development team. The process will then work as shown in the diagram below.

The product owner submits tickets to the backlog. The space owner and designated tech leads validate and refine the tickets, sort them in order of priority, and assign them to individual teams (in the diagram, “T1,” “T2” and “T3). They then select the most important tasks to go into the “Current” milestone (or the current Scrum sprint, or the Kanban process).

Each development team can see ts own tickets in the Milestone, Planner and Cardwall views, sorted by priority. They also see only their own messages, documents and repositories.

The space owners and tech leads can always see the “big picture” and communicate with all of the individual teams, while the team members can focus on their own artifacts, without needing to filter out work from the other teams.

There are several variations on this use case. For example, tasks can be assigned to Git forks or Subversion branches, and each fork or branch can be managed in a child space. 

Use Case #3: Many projects supported by many teams

 What if you need to support multiple clients with multiple development teams? Space Manager and Tags can help you there too.

You can set up a “Master Space” for the entire organizations, “Child Spaces” for each client, and child spaces for each development team.

Now tickets are tagged by the source (client, product owner, etc.) and by the assigned team. Managers can maintain the master backlog and see the global view at all times. Teams can focus on their own tasks and code. And clients can be given a limited view of their own tasks. 

How to use Space Manager

To see how to set up a master space and child spaces, see Vadim Todorov’s blog post: Team Management like a Boss

To learn more about using Tags and Space Manager see Andy Singleton’s post: Long Ticket List? Tag with Features, Teams, Clients

Space Manager is available as part of Assembla’s Portfolio feature pack.

When people think about continuous delivery, they think about speed.  They want faster delivery of high priority requests, from idea to release.  However, we found that we use the capacity that we get from continuous delivery to reduce stress, rather than increase speed.

I think that the stress reduction comes from three sources:

1) Things get fixed faster.  Problems don’t have time to build up.  If you have to wait many weeks to get a fix for a problem, stress builds up in that time.  Everyone affected by the problem is working around it and asking questions and applying pressure.  It feels better to just deploy small fixes and improvements can get deployed quickly.

2) Complicated work can take longer.  Everything gets finished on its own schedule, so you can take a long time to finish and test something complicated.  You don’t have the added stress of trying to fit it into a particular release.  You can use the extra time to improve quality and confidence.

3) Less work.  You can remove some batch planning work, including iteration planning, release planning, and status reporting.

If you use the “component” field within Assembla’s Tickets Tool, this post is for you. The component field has been removed as a default ticket field. If your project used the component field, don’t worry, we have maintained this field within your project as a “custom field” that's still available on all tickets. New projects created will no longer have the component field by default, but if you miss it, you can easily create it as a custom field. We encourage new users try the recently released tags for tickets feature thats provides similar functionality with enhanced filtering options.

So how does this affect you?

The default "Active by Component" and "Closed by Component" filters are no longer available. If you or your team used these filters, you can easily bring them back by creating a custom filter, grouped by component:

• From the ticket list view, click on “Filter” in the upper left to expose the report builder.

• Set “Sorting and Grouping” to group by component and set to only show tickets that are open. This will create a report similar to the previous “Active by Component.”

• When you are done building the desired report, scroll to the bottom, name it, and save it. You can “Share with team” where all team members have access to this report in the “Team Filters” section of the filter dropdown.

Now that the component field is a custom field, instead of an Assembla default, you can edit the properties or remove it by going to your Ticket Tool > Settings subtab > Ticket Fields section.

Ticket Tool Tip:

Did you know you can change the default filters and views (Ticket List, Cardwall, and Planner) from the Settings tab of your Ticket Tool? This saves time by immediately placing team members on the most used filter and view when they login to your Assembla project.

Integrate your Bitbucket repository into an Assembla project workspace. 

Today, we are glad to announce an integration with Bitbucket that allows you to keep your code in Bitbucket’s Mercurial repositories and use the power of Assembla's Tickets Tool for project management.

Configure in three easy steps

1. Install the Bitbucket Tool by visiting the Admin tab of your project workspace > Click the "More" button within the Tools section > Under the Repositories section, click "Add" next to Bitbucket.

2. Put your Bitbucket URL in Bitbucket Tool Tab:

3. In Bitbucket, configure Post service by copying URL from Assembla Config:

Update tickets with Bitbucket commit messages

• Link tickets to commits - use “re #1” or “re assembla-1” to reference a ticket in a commit message. A comment will be created on the ticket notifying everyone about the commit

• Change ticket statuses - just naming a ticket status - “Fixed #1” - will place a link in the ticket to the commit and change the ticket status to Fixed.

• Track time - enter a record of how much time you spent working on a particular task by using  “Fixed #1 Time: 1h30min” to your commit message.

I started following a LinkedIn discussion on the ever-popular topic "Can Agile work with geographically dispersed teams?"

Since 80% of all software teams are dispersed or "distributed," working with geographically dispersed teams is not an option.  You have to make it work, and we will help you.  We’ve been working for years to make distributed teams more agile, and collecting tips and tricks.Last night I pulled together this material and added it to the draft of our upcoming eBook, Unblock: A Guide to the New Continuous Agile.

Sections include:

Three ways to organize, Co-located, Outsourced, Distributed

Communications: A good online ticketing/issue system (like Assembla's) is required.  We also  recommend chat, online standup report forms, daily or continuous builds, and code review.  We do NOT recommend conference calls and other synchronous communication.  What do you think?

Do and Do Not: These core recommendations are simple and will save you a lot of time.

High performing teams, in which we explain how teams will become high performing after they succeed in working together, even if the team members have never met each other.  This position is supported by research, as well as by our own experience.

I would appreciate it if you check out this draft material and write your comments on the LinkedIn discussion group that we set up for Continuous Agile.

Here are some representative comments in the LinkedIn thread:

Allen Holub writes:  "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."  "Distributing the team is always a mistake. Have different teams in different locations can work, but you *never* want to split the team up." 

Andy's response: A lot of people made the argument that projects can be distributed, but you want to put complete teams in one place.  To me, this doesn't match reality, and it uses people poorly, essentially discriminating against people in some locations.

Carleson counters with "The teams must be equal".  That's right.  You want everyone to participate equally regardless of location.  However, he also says "Invest heavily in video equipment", which is wrong.  Most teams are just annoyed by video.

However, there were also a lot of people who say they are getting good results with their distributed teams.  These people didn't give up.  They kept trying things until they found good ways to communicate and collaborate.

We run a distributed team working in 15 countries, with multiple releases per day. This is a common architecture for modern startups. People who say they can't be agile with truly distributed haven't taken the time to learn how to do it.  They bring in a lot of assumptions about how teams communicate, and they haven't opened their minds to real behavior in a distributed workplace.

Github Repository Backup

Github is a great service and very reliable, but your code is so precious you back it up in several places just in case it is unavailable when you need it most. Occasionally, Github does go down, it’s a fact of life. With Github having 99.69% uptime over the past year, that means about 27 hours a year your code is unavailable. It is time to get that code elsewhere, so you can continue working withoutanyhiccups. An easy way to always be moving forward and collaborating while Github is getting back up and running is to use a free Assembla repo as a mirror.

A mirror is a duplicate of your work. It is a point in time, just as most backups are not real-time, the mirror must be pushed to in order to get back in sync.  If you end up pushing data directly to an Assembla mirror while Github is unavailable, you will have to sync (push) that data back to Github once it becomes available again.  The mirror is just another fork of your data, that must be maintained and updated regularly.  

To setup a mirror from a local repo, all you have to do is add a remote to your git repo and then push to it with the --mirror flag. By using the --mirror flag in your push, all references and branches are pushed, it’s a complete backup. Any Assembla repo will work without any special setup, using an empty repo tool is easiest.

Remember, you will control when the mirror is updated, so you must push to this new remote each time you want to sync from your local repo to your mirror and push to your Github repository as well. I will show you how to make a nice trick for this as well at the end.

Steps:

1. Clone your Github repo locally

# git clone git@github.com:<GITHUB_USERNAME>/<GITHUB_REPONAME>.git
# cd <GITHUB_REPONAME>

2. Add the remote Assembla repo to your local Git repo

# git remote add assembla_mirror git@git.assembla.com:<ASSEMBLA_REPONAME>.git

3. Push to your Assembla mirror repo

# git push --mirror assembla_mirror 

A Contest for Hackers

Recently we released an exciting feature, Server Side Hooks for our hosted Git and Subversion repositories. Today we present to you our first Community Contest - write Server Side Hooks to get Assembla for free.

What can You do with Server Side Hooks?

Anything. Automate your workflow - reject commits that you don’t like (no commit message? tests do not pass? does not comply with a coding standard?), trigger events on external services, rename branches... You know, it's software, anything is possible.

People have submitted two hooks so far:

• A Subversion hook that validates php syntax. Install it and never see anyone committing non-working code again. Thanks Jakub!

• A Git hook that validates the commit message based on a regex and rejects if it matches. It defaults to looking for “wip” in the message - any commit message containing text “wip” will not be accepted to the repository. Thanks Ido!

This is just the tip of an iceberg of what is possible. Go crazy!

How to participate

1. Submit a server side hook for Git or Subversion via Merge Request to our hoook repository.
2. Tweet it out - don’t forget to include @assembla and #serversidehooks
3. When your hook is accepted and merged by our team, you win 25 Assembla subscription dollars, and your entered to win amazon gift cards that will be given out at random to participants.
4. Submit as many hooks as you want.
5. The Subversion and Git hook that is most installed in Commercial spaces at the end of the contest wins an additional 250 Assembla subscription dollars.

As more people submit hooks, we will unlock more prizes.

Submission and Review

Get submissions in by July 31, 2013 to be considered for the contest. We will make our final determination of winners on August 31, 2013. 

Read more about submitting hooks (and our review policy) on the hoook wiki. Refer to this list to see all the participants.

Have fun and good luck automating your workflows!

Need help?

If your project has the Tickets tool installed, you will notice that the Milestones tab has been removed from your project's main navigation. You can now find it as a subtab in the Tickets tool.

A long time ago, we put Milestones on a separate tab because we were migrating users from Trac tickets, and Trac put Milestones on a separate tab.  However, in reality, Milestones is always part of a Tickets tool. We removed the special case where adding and removing Tickets also adds and removes the Milestones tab. This will also reduce the amount of tabs in your project's navigation.

You can read more about Assembla's Ticket tool here.

Post-it notes have a glamorous role in the world of agile Scrum and Kanban teams.  They represent the power and intimacy of small team.  Using post-it notes, you throw out ideas with a satisfying squelch.  You rearrange and reorganize your task board on a whim.

However, post-it notes also cause problems.  They are bad for distributed team members, or even for someone who happens to be home with a sick kid.  If someone is not in the room, handling the paper, they aren't included at all.  There is only one version of posted truth, and alternative organizations are not considered.  Worst of all, you throw them away at the end of an iteration.

Post-it notes are an instrument of oppression and control.  You use them to control access to the task board.  You use them to oppress anyone who is not in the room with you. You use them to erase institutional memory and rewrite the past.

In a world with lots of good online ticketing and issue management systems, there's no excuse for the tyranny of post-it notes.  You should put your notes and task boards online where everyone can comment, and you don't lose the information.

In Assembla's ticket system, we try to include everyone in an online conversation:

• We contact the correct people with "follower" email alerts, and a real time activity feed showing comments
• @mentions in tickets and comments draw users right to the point where they can reply
• Tickets show a complete history of the discussion and work
• A cardwall provides a shared team view (Renzoku package), and can be set as the default view for your team.

If you have design tasks piling in your backlog this blog post is for you. With the introduction of Continuous Delivery practices, the speed of the code development from the ticket to production has increased significantly. As a result, there is an increased pressure for the designers to keep up to speed. In this article, we will give you a few guidelines to unblock design tasks.

The fastest way to speed up design tasks is by using Standard Styles. Standard styles focus on creating reusable elements for consistency and recognizable components resulting in a better experience for all. Here are some of the common guidelines to start using Standard Styles:

• Document standard styles in a Style Guide
  A style guide  defines best practices for HTML and CSS with an emphasis on better reusable markup for both designers and developers. 

• HTML and CSS Organization
  Organize the Standard Styles into sections like: globals, components and layouts. The global styles includes typography, forms and common elements which can be reused for components. Components are made up of global styles. Each component must make sense as an independent unit. Layout styles define the organization of components in a page.

• Semantic Code
  Semantic code makes components more understandable by improving the code readability. Use HTML according to its purpose. The name of the classes must refer to the content itself and in some extent show the intended behavior (for example .s-list-expandable corresponds to a component type list that is expandable).

• Reusable Styles and Utilities
  Avoid creating new CSS rules and use styles provided. Use utilities instead for small tweaks. This should deter both designers and developers from adding more styles that are not needed.

Standard Styles makes the design process more efficient and productive. But, why?

First, it gives your team a start point for every project. The components system is sufficient to create basic mockups. You can literally post a wireframe and get a html mockup in an hour. This results in faster reviews and faster iterations.

Second, it allows developers to create features or improve existing ones without the need of a designer.

Third, it speeds up cross browser testing. It’s easier to test a single component than testing all the views of your app in different browsers.

Fourth, it allows designers to focus on new challenges and reuse solutions that have already been defined before in the Style Guide.

Last but not least, it improves consistency across the app and reduces discussions regarding a component’s behavior.

Ready to start using Standard Styles in your team? If you want to check how Assembla’s Style Guide looks, click here. You can more about how to accelerate software development, check out Assemba's free ebook "Unblock! A Guide to the New Continuous Agile."

If you have any questions or suggestions regarding the use of standard styles, please comment here.

 Many Assembla projects have moved beyond a simple list of tickets.  Our users are organizing projects hierarchically with parent and child tickets.  They are also working with agile methodologies that do planning at the Epic, Story, and Task levels.  We have added a new field called "Plan Level" to Assembla tickets.  This will help you add parent and child tickets at multiple levels - Epic, Story, and Subtask.

Story is the default type.  Any ticket that you create will start as a story. 

You can add Subtasks to a story on the planner, sidebar, or Related Tickets tab.  Subtasks are steps to complete a story.   They help you organize design, development, and bug fixes before the story release.

Epic is the top level.  An Epic describes a big feature that you will implement over time, by releasing a series of stories.

Why are they different?

In previous versions of Assembla, you could add child tickets to any ticket.  You did not need to worry about the "Plan Level".  The new system has types with different behaviors.  Most of it will work as you expect, by default.  However, it is more complicated.  Why do we need these new types?

When you move a Story to a new milestone, you move all of its tasks.  Tasks are tightly attached to a Story.  We assume that tasks are always finished at the same time as the parent story.  You cannot move a task to an implementation milestone like "Current", without moving the parent story.  You release a story, not the tasks.

If you have an Epic in your backlog, you can move its stories to the Current or implementation milestone one at a time, and release them one at a time.  Stories are loosely attached to an Epic.  So, you can finish Epics incrementally.  You can "Implement feature 1" and then later "Implement improved feature 1".

Our users have posted many requests about child ticket behavior.  Some people want stories.  They want to attach a set of tasks, and have those tasks move to the Current milestone with the story, and then get closed when the story is released and closed.  We implemented this behavior on the Planner.  Some people want epics.  They want to make an outline with a list of stories under an Epic or topic, and then move each story to implementation at the right time.  We implemented this behavior on the Outline.  To resolve the conflict between these two views of how child tickets should behave, we created the different plan levels.  These plan levels match the different ideas of "Epic" and "Story" in most agile methodologies.

Setting the Plan Level

The default Plan Level is Story.  If your Plan Level is empty, your ticket will act like a story.  You can set the Plan Level to Epic or Story in the sidebar field.  When you create child tickets of an Epic, you will create stories (loosely attached).  When you create child tickets of a Story, you will create Tasks (tightly attached).  It sounds complicated, but it will work by default.  You can only create Tasks by adding them to a Story.

The Outline view will automatically create types at the correct level, with Epic at the top level.

Using Stories

Stories make your planning views smaller and easier to manage.  They describe the important features that you want to release, and they hide extra details in subtasks.

It is a good practice to plan your backlog with stories. Then, when you move a story to the current sprint or milestone, you expand it with more detailed tasks.  We show stories on the Planner.  You can open a story and add Tasks in the Task tray under it.  You can also track individual bugs that needs to be fixed before the release of a story, by adding them to the story as Tasks, using the sidebar or the Related Tickets on the Story ticket.

Using Epics

Epics are a new feature to help you organize bigger backlogs.  You can sort a list of 20 or 30 stories into a sorted backlog.  After that, you will want to organize them by topic, or "Epic." 

The child ticket in an Epic is a story.  Stories are not strongly attached to their parent Epics.  You can take stories from an Epic, one at a time, and move them into different implementation milestones. 

Why use Epics?

• You can work with bigger backlogs.  You will organize the stories in each Epic as a separate topic, without looking at the complete backlog.
• You can distribute planning work to more people, by assigning different Epics to different people.
  
• Epics help you to be more agile, because you can finish stories one at a time, and implement the Epic incrementally.  You want to release frequently and incrementally.
• And, Epics help you see what is completed.  You can see what stories are done, what stories are in progress, and what  are in the backlog.

One of our Assembla teams created a special milestone called "Epics" for our Epics.  We can select the Epics column into the Planner backlog column, and see the high level topics that we are working on.  The Outline clearly shows your Epics in the left column.  And, you can select the Epic type as part of a list filter.

Views of the Plan Level

On the ticket sidebar, you can set Plan Level to Story or Epic

The Related Tickets tab shows you child tickets

On a Story, the Related Tickets tab helps you add Subtasks.

On an Epic, the Related Tickets tab helps you add and manage and schedule Stories.

In List view, icons show the parent Epic in green, parent story in orange

Stories on the Planner - add or drop Subtasks

Epics on the Planner - see stories, and link to the related tickets page to edit

This is a tricky one. If we allow you to drag and drop stories, you will see them in two places - under their home milestone, and under their Epic.

Outline view will enforce the Epic / Story Task Hierarchy.

Next week, we will make changes to the Outline view.  We are still testing these changes, and they are not deployed.

When you create Epics in Outline view, you will see them correctly in other views.

The Outline view is useful for building Epics, and for planning your work in progress by dragging stories from Epics, into the milestone where you want to implement them. 

The Future of Epics

If you’re a manager of multiple projects and teams, then Assembla's new portfolio activity reports will save you a lot of time by providing more fine-grained visibility across projects. 

• Save time by tracking activity across multiple projects from one report. No need to jump from project to project. 

• Oversee all work in progress and identify slowdowns in your team’s activity.

• Detect changes and inconsistencies with the key activity metrics comparison meter. 

How? Go to the Tickets Tab of your portfolio and click on Activity Report. Select a group of spaces and a timeframe, hit Update and voila!

The new reports are only available to subscriptions that have Assembla's portfolio capabilties. Learn more about Assembla's portfolio features. Existing subscriptions can upgrade and add portfolio features by visting your account page. 

Have suggestions about new portfolio reports? Let us know by commenting in this post.

Elettro is a digital agency whose roots stem from building social websites and applications for clients. While doing so, Elettro saw an opportunity in the market to create a simple yet powerful suite of Facebook applications to help businesses, bands, and celebrities build their brands. The end result was Elettro Social Platform (ESP), which was recently released out of beta and is already being used by thousands of organizations, including Assembla, to maximize a brand’s usage of social media and Facebook.

Dean Palermo, CEO/Founder or Elettro, Inc. said: “My development team spans six time zones. We have been using Assembla for over two years to manage client projects. When the idea for ESP came about, it was only natural to immediately create an Assembla project and start planning and organizing tasks as if we were in the same room.”

The social platform is comprised of 8 Facebook applications, and is managed from one Assembla project because Elettro likes the flexibility to have tasks lumped together as one sum of work. Their team lives in the Cardwall view of the Tickets Tool where current work is organized in a prioritized list. When a developers finish work in progress, they simply grab tasks from the top of the “New” column. “I feel like I could go away for weeks and the team would be fine,” said Dean.

Other features that the Elettro team uses to organize and manage their business include:

• Ticket tags to see progress for each application and components of the platform

• Stream to oversee daily progress

• Messages to collaborate on new features prior to ticket creation

• Wiki to store development on-boarding and legal documentation

• Google doc integration for real-time collaboration on marketing materials

“Assembla is a stress reducing tool,” said Dean. “Having all tasks and collaboration in one place dramatically speeds up our processes and allows our team members to stay focused while working together from across the globe.”

If your brand is looking to boost social interaction with Facebook, checkout Elettro’s Social Platform. It is free and allows you to quickly add Twitter, Instagram, YouTube, RSS, Pinterest, Pinto, photo contests, giveaways and sweepstakes directly your brand's Facebook page. 

Have a large Backlog? Hate sorting the entire thing? Want to move fast and continuously? Then stop sorting your entire Backlog.  Just don't do it.

Instead, sort only the important tasks to the top of the Backlog, once those are done, or more appropriately, starting to dwindle, then sort the next batch of tickets to be used.  This ensures you are not wasting time by:

1. Not sorting tasks that will never get done
2. Sort only the priorities you can handle now
3. Allows you to shift priorities quickly
4. Keeps your tasks prioritized
5. Allows you to create a Pull system
6. Preventing work on not-ready tasks

The Ready-line keeps important tickets at the top of your Backlog in the Planner view, preventing them from getting lost. Drag-and-drop the bar to the desired location or drag and drop tickets into this area to separate work that is ready to be worked on from work that is still be flushed out.

Tickets above the Ready Line can be easily moved into your Current milestone or vice versa. This ensures that the most important tickets are next in the queue while giving a clear area for your developer's to pull work from.

To get a free Assembla Renzoku plan with the Ready-line, sign up here

Luxurious Animals is a creative agency based in New York City that inspires and engages audiences through interactive digital media such as websites, applications, games and video. Their impressive portfolio boasts well-known brands such as Adobe, Porsche, Bombardier and Morgan Stanley.

Dan Federman, Technical Strategy Director, went on a mission to find the perfect tool to organize and manage both internal development projects and development projects for clients. After searching and evaluating many options such as Asana and Basecamp, Luxurious Animals fell in love with Assembla. “Assembla provides the exact suite of tools our teams need,” said Dan. “If I were going to build the perfect project management application, it would mirror what Assembla has built.”

All new projects begin as project templates pre-configured with the desired tools, settings, milestones and branding, and set up for their typical development workflow. Using Assembla’s project template feature this way allows them to get new projects up and running quickly and easily.

Luxurious Animals uses tickets to manage all projects, from current tasks, to client requests, to their “ice chest” of cool stuff that there may or may not be time to complete. They have customized their ticket workflows to include an “Acknowledged” status for tasks that are at the front of the queue, ensuring the development team understands requirements and knows what to work on next. A daily standup is conducted while looking at the Cardwall view of upcoming tasks, so that the team understands what everyone is working on now, next, and if there are any obstacles to address.

All code is managed through Assembla’s integrated Git repositories. According to Dan, “the Git integration is a big time saver. Developers can easily update tickets via commits, and deploying code to staging and production environments is effortless with the FTP Tool.”

As task and code move from concept to reality, clients work side-by-side with Luxurious Animal staff to do their own testing and analysis. Every client project has the Support Tool installed, allowing clients to directly submit issues and requests from their own testing. This ensures that clients approve changes and features and address issues before applications are released to millions of consumers. Since implementing Assembla into the development workflow, Luxurious Animals has seen a noticeable difference in project release times and client satisfaction.

It has been over a year since Luxurious Animals started using Assembla. “We love how Assembla constantly grows and improves,” said Dan. “It is as if Assembla anticipates all of our needs.”

You can learn more about Luxurious Animals at www.luxanimals.com.

Assembla servers have been upgraded to Apache Subversion 1.8. This new release includes some new features and many improvements. The release notes are here: http://subversion.apache.org/docs/release-notes/1.8.html

You can download a new 1.8 client here

Subversion 1.8 makes big improvements in the merge operation. You don't have to figure out a long sequence of revisions and options. The merge operation will figure out the correct form of the merge. You will not have to track revision ranges, because the improved merge is much more likely to merge the changes that you want. You can update your working branch.

With the improved merge, you can use temporary branches and Assembla merge requests to review and accept code. You can put your changes into a temporary branch, and your operations to update the temporary branch and then merge it to trunk will work correctly. With the added quality from this code review, you can scale up your existing process to more team members. Your trunk will be cleaner, and you can run centralized continuous delivery.

Subversion 1.8 also tracks file and directory moves. In the past, when you move directories around to arrange your libraries and components, this often created a conflict with the central repository version. Now, your "update" after a move is much more likely to work correctly.

I want to give my thanks to Julian Foad and the rest of the Apache Subversiont team for taking up the request for improved Subversion merge, and making these improvements.

From the release notes: "Before using Subversion 1.8 with existing working copies, users will be required to run the svn upgrade command to upgrade working copy metadata to the new format. This command may take a while, and for some users, it may be more practical to simply checkout a new working copy."

Assembla is the world's best Subversion host. Learn more here.