Current Articles | RSS Feed RSS Feed

Installing Assembla behind the firewall

Posted by Andy Singleton on Mon, Jul 16, 2012
  
  

 

Customers asked for a version of Assembla that they can install behind the firewall, so that they can control security and meet policy requirements for controlling code location. 

We responded with the “Assembla Private Install”, a complete version of the Assembla server cluster, packed into a virtual machine image.

Complete Private Install:  Get all features including ticketing and task management, collaboration, portfolio management, etc.  Price begins at $200/user/year with volume discounts.  Read more and request a trial at http://portfolio.assembla.com/private_install.html.

0 Comments Click here to read comments

“Everything in One Place” is a Big Deal

Posted by Jon Friedman on Thu, Jun 23, 2011
  
  

An Assembla "space" keeps everything in one place.  In this case “everything” means all of the code, tickets, comments, messages, files, wiki entries and chat sessions related to a project, and "one place" is the workspace for that project.

When I joined Assembla my reaction to that characteristic was: “That’s nice, but how important is it really? These days everything is on somebody’s hard drive, or stored in the cloud. Nothing is going to get lost.”

But I’ve come to realize that “everything in one place” is a big deal, on three different levels.

1. On the personal level, it saves me a lot of time. Sure, all of my work files are on a hard drive somewhere. But then someone asks for a paragraph I wrote three months ago. Which directory did I put that in? Is it in a Word file, or was it on a PowerPoint slide? Or in an email in my gmail account, or my Exchange mailbox? No, maybe it was from a Skype chat? And there goes an hour of my life searching all those places.

With Assembla, if the paragraph is related to project XYZ, then I can look in the activity stream for that project, or go right to the one or two tools where it must have been entered.

2. On the team level. Now I don’t have to worry that Jeff or Nadia's hard drive has a crucial file that I need right now, at 1:00 in the morning. And when someone new joins our team, they can come up to speed quickly without a lot of handholding. They can see everything, not just the code in the repository, but all of the tickets completed and opened, and all of the ideas that went into planning and managing the project. Those factors can have a measurable effect on getting the project done faster.

3. On the business level.

(A). Companies are now shifting staff around between projects all the time, so being able to bring new members up to speed quickly is not just nice to have, it is a facilitator for the whole business model.

(B) What happens when somebody gets sick suddenly, goes on vacation, or quits? If a crucial document or piece of code is on their hard drive, or in their desk drawer, the company misses deadlines or loses money duplicating work.

(C) “Everything in one place” offers a kind of insurance policy for customers (external or internal). If the team can’t complete the work for some reason, the entire project can be handed off to another development group, specifications, code, task list, test plans, documentation, and all. That dramatically changes the risk profile. The risk is no longer losing an entire six or twelve months' work. The worst case is now needing a few days or weeks for new people to look at all of the documents and code and come up to speed.

Some custom development shops have turned this attribute into a major selling point with their customers (see our blog post “Can Agile work with client projects? Gravity Jack’s Way”). But the same principle applies to enterprise IT environments as well.

So “everything in one place” can be a pretty big deal after all.

Now if only I could figure out where I put that paragraph they asked me for...

6 Comments Click here to read comments

Dr. Dobb's Journal on Assembla Portfolio

Posted by Jon Friedman on Wed, May 25, 2011
  
  
Tags: 

Dr Dobb's article on Assembla PortfolioDr. Dobb's Journal ("The World of Software Development") just published an article: Assembla Assembles Assembla Portfolio at: 

http://drdobbs.com/architecture-and-design/229500791

We're not too sure about the title, but we like the concluding statement: "...the company's offering shows evidence of Agile developer community power when coalesced."

0 Comments Click here to read comments

Launching "Portfolio" - For consultants, enterprises, communities

Posted by Andy Singleton on Tue, Feb 15, 2011
  
  

An Assembla workspace is a power tool for one software team. If you have a lot of teams or clients or projects, you need the just-released Assembla Portfolio.  It gives you a place to see all of your code,  tasks, and activity, and get all of your people connected.  Read about it at portfolio.assembla.com.

We built Portfolio with three use cases in mind:

Client projects:  Many of our subscribers are consultants, outsourcers, and agencies that are doing work for clients.  For them, we've tuned Portfolio with branding, client views, time reporting, and unlimited projects.

Enterprise: With Assembla Portfolio, organizations can benefit from a centralized portal that shows them what is going on, and collects all of the information from each project in one place for future maintenance.  And they can still support their various decentralized teams and outsourcers and suppliers with a choice of tools, repositories, and workflows. For them, we provided Stream views,  Ticket reports, centralized user management, project templates, and Manager roles.

Community: Software platform providers range from small open source project, up to SAP.  They want to share code, work together on software, and build engagement.  For them we have public portfolio views,  project propose/approve workflows, and ongoing innovation in code contribution workflows.

We've been working on Portfolio for the last six months, and for the last two months I have been using it every day to look in on teams and team members.  Now, new customers can get a portfolio on-demand in sixty seconds.

The Portfolio view can be laid on top of your existing spaces.  If you are already a subscriber, you can get a free 30-day beta trial of Portfolio by grabbing your Portfolio name at this top-secret location.  Or, get a free Portfolio for open source or other publicly visible projects here.

Packaging

Subscribers pay $20 per "core" user per month, and get unlimited projects, and unlimited "watchers", who can be clients, bosses, or other hangers-on.  There's no reason not to be transparent, and you can keep all the information about all of your projects ready to go.

Public Portfolios

In a public portfolio, the activity Stream and Spaces list are shared with all visitors.  Users can fork, or they can start new projects by grabbing the templates that you provide.  I'm not sure that all of these workflows are exactly right, yet, but it's going to be fun when it revs up.

And there's more coming...

For users of our existing Workspaces, there is a lot of stuff still coming in our Q1 upgrade blitz - localization, custom status and custom workflow, Kanban, and big repository upgrades. We will be peeling back the layers on these features over the next month.

Screenshots

Edit the home page, logo, and style

branding

Make project groups or user groups, and save them as filters. Voila, you have your own private view of the world.

space filter resized 600

See a ticket dashboard for all projects, or for a selected group like internal development projects.

ticket dash resized 600

Click through from any of the dashboard categories and get a nice sidebar filter for further drilldown.  Yes, we are going to upgrade the Space ticket tool to use this type of filter.

ticket sidebar resized 600

See what a user is doing across all of your projects.

user report2 resized 600

Projects can be Proposed, Active, Template, or Archived. Approve and reject proposed projects.  Set up pre-configured project templates for your adoring masses.

activate resized 600

 

Let us know what you think, and how we can improve this first release.

8 Comments Click here to read comments

SAP Code Exchange, with Assembla Inside

Posted by Andy Singleton on Sun, Oct 10, 2010
  
  

I'm in Berlin at SAP's Innovation Weekend, where we are introducing SAP Code Exchange, a portal for shared source projects related to the SAP platform.  For the first time, hundreds of thousands of professional SAP developers will have a place to find utility code and work together on bigger projects.  To build Code Exchange, we integrated SAP's developer network with a customized Assembla instance.

Open source code and processes are a key component of modern fast, lean, and global software development.  I like to think about practices, things that you need to know to get benefits from this component.

  • First, you need to know how to do research to find and adopt appropriate code and frameworks.  That makes development faster.
  • Then, you learn to contribute to open source projects, so your customizations benefit from shared maintenance.  At a company level, this leads to sharing code with customers.
  • At an advanced level, you organize open source and shared source projects to support your vision of the world, your platform, and your users.   Every big software vendor will eventually have to learn and deploy these advanced processes, as SAP is doing.

SAP's Innovation Challenge

Project leader Rui Nogueira says "We built Code Exchange to encourage co-innovation, with innovations moving more quickly from customers to SAP, and from SAP to customers."  Kaj van de Loo, SVP of Technology strategy, talked about SAP's openness initiatives, and quoted Ronald Reagan, "tear down this wall".

Code Exchange was shaped to fit with SAP's shared-source licensing, their proprietary code management, and their active developer network.

SAP has a long tradition of sharing code, predating the open source movement, because when you buy their installed ERP apps, you get the source code.   Very cool.  In the license agreement, customer and integrators must agree to certain terms.  Code Exchange creates a compatible environment by asking all users sign a “terms of use” agreement that is compatible with the SAP shared source license.  Once they sign the terms of use, they get into a walled garden where everyone shares with common license terms.  They are breaking new ground with a type of shared-source licensing that can open up high-value, proprietary systems to the power of  sharing.

SAP apps are beyond the size that I can imagine managing, with about 150,000 screens.  SAP has specialized systems for version control and deployment to handle this beast.  We need ways to move code between their Netweaver development environment and internal ABAP repositories, and standard svn and git repositories.  For example, SAP advisor Gregor Wolf has been working with collaborators on the SAPlink import and export mechanism.

SAP has existing portals for their developer network, and the customer network (with 2M users).  They just released a new project collaboration environment based on Jive SBS.  The SAP team wanted to add repositories and ticketing, without confusing anyone.  Their vision was radical simplification.  We stripped Assembla down to one project template with just the extra tools they wanted – Subversion, Issues (our Tickets), Releases (our Milestones), and Chat.

codex screen1 resized 600

What did we do?

So, how do we customize and deploy Assembla for an enterprise customer?

1) Start with our Private Assembla configuration.  This is a stand-alone configuration of Assembla without any of the subscription features, with source code.

2) Set up staging and production servers.  We got permission to use cloud hosting (see below) and started some servers in the Amazon EC2 datacenter in Ireland, bringing us inside the EU.

3) Fork the Assembla code into a new git repository.  With this structure and thoughtful engineering, we can easily merge new versions with our SAP customizations.  We also set up ticketing in this new space and invited the SAP team to work with us. We set up build scripts and continuous integration for the staging server.

4) Configure and skin.  We brought in a header and styles from the SAP Developer Network, as shown in the screen shot.  Strip it down to one project template and configure that template space.

5) We made a number of customizations, including: login/authentication to implement single-sign-on with their domain cookie; simplified start page;  release file posting; API authentication, and some API upgrades.

6) The Jive portal team at SAP integrated Assembla using the REST API.  They used the Space API to add matching projects, and the Tickets API to list  and post Issues, a subversion browser, and a new Milestones API to show current release files.

7) SLA and security compliance.  We asked for some adaptations to SAP's normal security policies, so that we could use cloud hosting.  We also took advantage of some of the work that Amazon is doing to meet enterprise security requirements. This is by itself an interesting subject, if you are involved in moving enterprise apps to cloud hosts.

Here's a video interview from Innovation Weekend.

1 Comments Click here to read comments

Introducing Private Assembla, your own Assembla server in Download, Cloud, and Managed packages

Posted by Andy Singleton on Mon, Aug 03, 2009
  
  

Today we are announcing Private Assembla - your own Assembla server.  You can find out more about the packaging on the spiffy new Web site at private.assembla.com.

You can get Private Assembla in three packages:

  • Download - a VMware image, with a 30 day free trial and a perpetual license
  • Cloud - an Amazon AMI
  • Managed - You call, and we set it up and maintain it

You also get complete source code, technical support, etc.

Here are some things that I think are interesting about this.

We're doing a simultaneous release of the download and the Amazon image.  We think that distributing software through cloud hosts like Amazon is going to become an important trend.  It certainly makes it easy for you to try the product.  If you have an AWS account, you can fire up an image, run the configuration, which takes about 5 minutes, and pay a few dollars for a few hours of unlimited use.  We're also offering a Managed service that makes it even easier.

The usual enterprise software strategy is to start with an installed product (which costs more - good for revenue) and then package it as an online service/ Software as a Service.  We're going backwards and starting with the online service.  We think this is an important contributor to product quality.  We get a lot of feedback from our Internet users, and we have to make a good product because we have good competitors.  So, the Internet product has to be better than a typical enterprise software product.  Google has been pitching this idea as a reason to buy gmail and Apps for Domains, and I think it's a good argument and a good product strategy.

We are doing a little bit of innovation in licensing, to make things easier for our customers.  The license doesn't contain any restrictions on copying (one of my pet peeves), or code modification, and the software doesn't contain code to force you to enter a license key after 30 days. Instead, we ask you to report the number of active user accounts.  The images come with a script to "phone home" with this information.  If you want to disable this script, just contact and arrange a different reporting mechanism, which might just be a manual report.

We wanted to highlight some of the work that we are doing with enterprise customers, both on methodology to accelerate software development, and on tools.  So, we issued a corporate-style press release, here.

That said, the most popular request is for the 20 user download, for users that want to satisfy with network security requirements. 

I look forward to working with all of you to improve this product.  It's a complex product under a simple shell, with many servers and processes packaged into the virtual machine image.  We have done a lot of work on the installer, and on building the VMware and Amazon images consistently, and we will continue to work on the portal UI, and the  upgrade process and on supporting other cloud hosts.  Our goal is to deliver a product that is easy to set up and use out of the box, but still allows users to get involved with customization if they want.

0 Comments Click here to read comments

Surviving and Thriving in the Best of Breed Web

Posted by Andy Singleton on Fri, Oct 17, 2008
  
  

About six months ago, we noticed we were getting our butts kicked.  As I talked to leading edge developers, I found that many of them were not using Assembla.  They said they liked Assembla, but they wanted to use some one tool that wasn't on Assembla - a repository, or a messaging system.  They ended up registering every team member for several different services, to get the capabilities they could get from Assembla all in one place.  For them, the single team list and login at Assembla wasn't a benefit.  They were willing to put up with the hassle of multiple accounts and kludgy Web services, because they wanted Best of Breed.

This is a major trend in Internet buying behavior.  It will affect everyone that sells application services.  Read on to find out what we are doing to survive and thrive on the Best of Breed Web.

To see how Best of Breed becomes a powerful driver of buying behavior, consider a situation where a user needs three capabilities - a code repository, a message/discussion system, and a ticketing system.  Imagine  that Assembla provides a capability in each category that is competitive with the best service available anywhere else in the world.  In this scenario, Assembla is awesome.  When comparing Assembla's integrated feature with the best feature available in the world, a user will select Assembla 50% of the time.  Even in this case, the awesome Assembla case, there is only a 12.5% (1/8) chance that Assembla will be preferred in all categories.  87.5% of the time, the user is tempted to go with best of breed

On the Internet, an application that tries to force the user into a complete and isolated solution (as our users suspected Assembla was doing), will only get a small percentage of users.  On the other hand, if an application is clearly best of breed in one category, it can wedge itself into the best of breed bundles for many users, and benefit by getting links from all of the other apps.  You can offer a complete solution - many people will appreciate the convenience - but the first rule is that you need to be best of breed at some one thing.  That one thing is what gets you into a lot of bundles.

We needed to find our entry in the best of breed race. Many of our users come to Assembla for Subversion, and often they come only for Subversion, so in the eyes of the marketplace, that was our best of breed slot.  However, Subversion is a commodity that is available from almost any hosting compay, which sets a very low pricepoint, even for our enhanced version.  We have been working to bring our Tickets tool up to best of breed status.  It's good, useful, popular, improving quickly, and near parity with the best of breed.  We will achieve best of breed with Tickets.  However, it's in a crowded category.  It would be even better to have a high-value, original, unique offering.

After thinking about this for a few weeks, and trying to work with disjointed best of breed bundles selected by clients, we realized that Assembla had a huge new opportunity.  The people who are running their teams with best of breed bundles have created new problems for themselves that need to be filled with new best of breed tools - Team, and Stream.  When we originally wrapped the Assembla application around Trac and Subversion, we solved those problems.

Team: The first problem is simple - keeping the team list.  If we can add team members in one place, and then replicate the team, we prevent problems for new team members, and if we can remove them in one place, we prevent security problems.  So, if we can replicate the team members or permissions from the Assembla team tab, we make life a lot more convenient.

Stream: You want to see what your teammates are doing.  This second problem is more complex, but more important for driving productivity.  I talked about this as Workstreaming.  Workstreaming is like lifestreaming, like a professional version of Twitter of Friendfeed.  However, it's more complicated because the you can't just share your work activity (events) with all of your friends.  The permission to see them is controlled by the project owners.  So these events get organized into permissioned project views like the Trac timeline or the Assembla Stream tab.  If we could gather a wide variety of events into the Stream and Alert system, we could build a powerful view of activity that would unify the team, improve communication, quickly expose and resolve issues, and provide visibility for managers.

So, in this new world, you want to make a list of the apps that your team uses, and have some godlike hub application replicate the permissions and show you everything that team members are doing.  In Assembla, it might work this way:

  1. Create an Assembla space with just the Team and Stream tabs
  2. Select the external applications that we use from the Tool list in the Assembla space.  These tools are "external" tools.
  3. Go to each tool tab, open the settings panel, and put in the information that allows us to connect to our account on the related app: user credentials, API credentials, RSS URL, etc.
  4. Use buttons on the tool page to replicate the team or data, if those operations are supported by the external tool
  5. See everything that your team members are doing in the related applications, run reports to see what happened, register for activity alerts to see what is happening now, and send the activity "events" to any of the related applications.

We went to work building the architecture to make it happen.  We streamlined our tool architecture to make it easier to add external tools, and started working on documentation for a development kit that outside developers can use to add their tools.

If we end up supporting hundreds of tools, then it will be confusing for users to configure them and connect them together into useful combinations.  So, we built a catalog where users can select a preconfigured combination of tools with a single click.

Introducing the Event Hub

Our most radical move was to build a new piece of infrastructure – the Event Hub – to let you see what your team is doing around the net. It collects events (code commits, ticket edits, new messages) from Assembla internal tools and displays them in the Stream and alerts.  It can ALSO capture events from external applications (for example, your external repositories), show them in the Stream and alerts, and ROUTE them to other external applications (in a simple example, Twitter). It’s like a permissioned friendfeed for a working team.

The Event Hub is a major piece of infrastructure for the Best of Breed Web.  It's necessary.  Without the event hub, every application needs to implement many interfaces to other applications, and there are millions of combinations.  For instance, if a repository system wants to post commit events to ticketing systems, it needs to implement a different Web service for each supported ticketing system.  With the event hub, the repository only needs to post commits to one system - the event hub - and from there they can be distributed to any supported ticketing system.

Enterprise - they prefer integrated

I will note that Enterprise buyers will prefer an integrated solution rather than a best of breed bundle.  Inside the corporate firewall, there is not as much choice to put together a bundle.  Enterprise buyers want software that meets a consistent standard of security, compliance, and support, and we've got a great integrated offer for them.

1 Comments Click here to read comments

All Posts

Follow Assembla

twitter facebook youtube linkedin googleplus

Subscribe by Email

Your email: