Codesion

Agile Estimation Webinar: Why don't we use time?

socollabnet — Wed, 16 May 2012 11:01:10 -0700

Join Codesion’s ScrumMaster and Sales Engineer Caleb Brown as he discusses hot Agile topics that face the software community. This interactive demo will discuss the why and a bit of the now when it comes to Agile estimation based on units other than time. Click here to register for our upcoming webinar.

Agile Estimation: Why don’t we use time?

Tuesday, May 22 at 10am PDT

Go Ugly Early - Limiting Risk in Agile Webinar Recap

socollabnet — Thu, 10 May 2012 06:01:25 -0700

A big thanks to our audience for making this week’s webinar, “Go Ugly Early - Limiting Risk in Agile” interactive and full of great questions. Below are the Q&A’s from our webinar this week.

Q: There are so many man-hours available for any project. How does Agile make the team work faster?

A: There’s no short answer to this, but I will try my best to answer accordingly. The team composition, self organization, cross functionality, and stability, practices like time boxing and ordered backlog, and finally a focus on what is produced (working, tested, and deployed code) instead of the old fashioned focus on just keeping people busy (as promoted by a focus on ideas such as man hours) are all contributing factors to how organizations who have fully adopted agile will typically see improvement. That improvement may not be efficiency, or speed for every organization, but agility will improve quality, consistency, and overall it will help an organization to build the Right software. Building valuable features a little more slowly is better than building worthless features efficiently and fast.

Q: What does “Go Ugly Early” mean?

A: Going Ugly Early is a bit of a paraphrase of something a customer once said to me. Basically he said that they liked to know as early as possible what the worst thing that could happen to them in the project would be, so they could start to figure out how to overcome it. That way they aren’t surprised by a huge problem 75% through the project when they couldn’t change course even though they need to. Ultimately agile limits risk constantly by showing us those risks as soon as we can get a hint that they might be there, allowing us to address them earlier rather than later.

Q: How do you know when a backlog item is “Done”?

A: When the team has shown that it works and the product owner accepts that the work defined in the backlog item is complete.

Q: Will agile tools help us adopt Agile?

If your tool does not force you to deviate from healthy agile practices it may help. Typically a piece of software is most valuable as an agile adoption aid when an organization is adopting agile at scale or when the teams are geographically distributed.

Q: Is it possible for distributed teams to practice Agile?

A: Yes. It’s not as easy, but it certainly is possible. How you do it is another very large topic. One piece of advice: try to keep your teams as close to each other in terms of time zones as possible. When your team members are in too many different disparate time zones meaningful communication becomes nearly impossible.

Q: What happens to the backlog when the priorities of the business or market change?

A: The product owner changes the priority of the items on the backlog. The backlog is a tool specifically constructed to manage constantly changing priorities.

On May 22, we will be hosting another Agile webinar. Read below to register!

Agile Estimation: Why don’t we use time?

May 22, 10 - 11AM PDT

This webinar will cover a lot of the why and a bit of the how when it comes to Agile estimation based on units other than time. Click here to register.

May 8 Webinar: Go Ugly Early - Limiting Risk in Agile

socollabnet — Wed, 02 May 2012 15:32:00 -0700

Codesion’s first webinar from its Agile Guru Webinar Series is kicking off next week! Attend our interactive session hosted by our ScrumMaster and Sales Engineer Caleb Brown to see how you can limit risk by going Agile. Tune in next Tuesday, May 8 at 9am PDT to learn more! Click here to register.

Below are a couple questions that will be addressed during our webinar:

Q: Why is Agile so much better than waterfall in the long term?

A: Limiting Risk.

Q: How does Agile uncover and ultimately limit risk?

A: By falling fast and reacting to that failure.

Go Ugly Early - Limiting Risk in Agile

Tuesday, May 8

9:00 - 10:00am PDT

Presenter: CollabNet ScrumMaster & Sales Engineer Caleb Brown

Announcing CloudForge - CollabNet’s NEW development Platform as a Service (dPaaS)

guymarion — Mon, 30 Apr 2012 06:01:22 -0700

It’s Monday, April 30 here in San Francisco, and we have officially just launched CloudForge in Public Beta- our new development Platform as a Service (dPaaS). CloudForge is something that we’ve been working on since early 2011, so we’re glad to finally be in production.

Our History & Philosophy

Since the early 2000s, we at CollabNet have envisioned that developing software in and for the cloud would be the mainstream way of working. Today, mobile, web, collaboration, and social apps have exploded, and PaaS/IaaS vendors like Amazon, CloudFoundry, and Force.com are now first-class citizens alongside Enterprise IT. Agile development organizations are developing faster, more nimbly, by using a heterogeneous mix of process and tools, provisioned on-demand and paid per use, with teams working remotely around the world.

With CloudForge, we were given the opportunity to reimagine our vision: providing an easy-to-use agile platform that offers the tools and services collaborative teams need to deploy to any production environment (private, PaaS, cloud). As a company who practices agile development and continuous deployment compulsively, we ourselves leverage a range of tools and environments, and so flexibility, interoperability and scalability are critical for us to be able to deploy to production dozens of times each day. We have incorporated many of these principles into CloudForge.

What is the CloudForge dPaaS?

CloudForge is a new development Platform as a Service (dPaaS) for developing, deploying and scaling application services. It’s fast, self-service, and designed to meet the needs of Enterprise scalability and security. It provides the broadest range of hosted tool services, platform services, integration services and deployment services available. The CloudForge dPaaS differs from an application PaaS like CloudFoundry or Heroku, in that there’s no runtime environment for application hosting.

Cloudforge is built in Rails on the same battle-tested, multi-tenanted infrastructure that has powered Codesion.com since 2004. CloudForge can be managed via the UI, or control can be customized using our REST APIs. Large customers like Devfactory (a Trilogy Inc. company) manage access controls (authorization) using our APIs, while channel partners like Elance and CloudBees are offering development services to their users from their local environment.

What programming languages and frameworks does CloudForge support?

CloudForge is a true development Platform as a Service (dPaaS) which means it is programing language and framework agnostic. It does not matter what type of application (mobile, web, cloud etc.), CloudForge provides the platform you need to code, manage, deploy and operate your next development project.

What environments can CloudForge deploy to?

CloudForge Publisher provides a direct deployment framework to any PaaS/IaaS and private datacenter environment. To help you make deployment as easy as possible, CloudForge already has preconfigured deployment target recipes for all major PaaS/IaaS (Like VMware’s Cloud Foundry, Joyent, Force.com, Google App Engine, Amazon EC2, etc.)

What are some of CloudForge’s key features?

The CloudForge UI simplifies routine tasks for managing and scaling your development environments. This includes adding/removing users from a central user pool, setting up tools and project workspaces, defining role-based permissions across multiple tooling environments, configuring email notifications, defining deployment recipes and targets, and integrating with popular tools like JIRA, Pivotal, and Rally. A typical customer scenario would be setting up the London-based R&D team with SVN integrated with JIRA, enabling the Boston UX team to continue using Git integrated with ScrumWorks for agile management, while enabling the Bangalore team to deploy testing and staging environments in Amazon.

Real-time activity feed in one place

The CloudForge Activity Feed is prominent in all Account and Project dashboards, and aggregates development activities within a single location. You can facet and search the feed, for example to see SVN or Git commits made to my branch by a certain team member. In coming months, we will be opening up the Feed to 3^rd party applications using our Data APIs. This might include build or test results, app downtime alerts, and artifact updates that can be pushed/pulled into the Feed.

Select and connect your apps instantly

The new App Center enables customers to host or integrate SCM and agile tools from the “My Services” zone, or activate integrations to a range of 3rd party tools like Basecamp, Rally, JIRA, or Pivotal. Note that we have built-in best practices and tips into the first-time user flow, to help get up and running quickly. The “Marketplace” section allows the account admin to browse and link to certified CollabNet partner applications, all of which are either compatible with or integrated with CloudForge.

View reports, integrate CloudForge SVN & Git into your workflow

The CloudForge reporting center provides insight for development leaders into coding activities, project progress, and user contributions, while enabling security and IT Managers to access system logs for compliance purposes. Customers can set up numerous integrations, using Web Hooks APIs (for example to fire off a build from a coding commit), commit-hook integrations (to update artifacts across a range of third-party services), and CloudForge Publisher for deployment.

How do I buy CloudForge services?

CloudForge is currently available as a Public Beta, which is free. Monthly or annual subscription plans will be available for purchase when CloudForge is made Generally Available (GA), in the near future. Again, the platform is built on established, highly iterated infrastructure, and we invite you to try it out and provide feedback. Please read our Beta FAQ to learn more.

Guy Marion is the VP & General Manager of CollabNet Cloud Services. Guy was previous CEO of Codesion.com, which was acquired by CollabNet in 2010. Connect on Twitter @guy_marion

Codesion Integrates with Zendesk!

hrmpw — Thu, 22 Mar 2012 09:57:54 -0700

Based on feedback from our customers we are happy to announce the integration between our enterprise-grade, cloud development platform and Zendesk, a popular help desk solution. Teams looking to automatically link work done by their development teams to customer issues are now able to complete this workflow. In fact, developers can even close (“Solve”) multiple tickets directly with a single code change.

Using Codesion’s commit message syntax a developer can link code commits to Zendesk tickets and automatically solve the ticket; all without having to change anything in your Zendesk account, your repository, or your cloud development platform client. Any Codesion Business Plan customer can simply add Zendesk support from the “Services” page of your project, add one set of user credentials to link your project with your Zendesk account, and start updating tickets. You can start from nothing to solving all of your tickets in a matter of minutes.

Codesion will automatically attempt to match the email address of the person making the commit with a Zendesk user within your account, attaching a private message to that issue. If the email address matches an agent with the appropriate access rights they can choose to simply comment on the ticket or close it.

Click here to read more on setting up Zendesk integration with Codesion Source Control.

Webinar Recap: Exploiting the Cloud for Speedy Development & Continuous Delivery

socollabnet — Wed, 14 Mar 2012 15:15:18 -0700

CollabNet and CloudBees partner together to provide an Agile Best Practices Webinar following the announcement of their partnership. This webinar shows how you can develop and deploy in the cloud, improve efficiencies and delivery times, reducing total overall cost of delivery applications.

Presenters: Willie Wang, CollabNet VP of Products & Engineering, Steven Harris, CloudBees Sr. VP of Products, and Harpreet Singh, CloudBees Sr. Director of Product Management.

Below is a list of all the questions asked by our attendees. Feel free to email us if you have any further questions.

Q: What are the different ways Jenkins can notify people when issues arise?

A: Jenkins can notify people of issues by Email, chat, and other channels. It supports a variety of protocols and transports so you can look into notifications by yourself. Likely, though, you will find a plugin that suits your needs within the “Manage Plugins” area of the Jenkins Update Center under “Build Notifiers.” In addition, Jenkins has built-in mechanisms for getting notifications to the right people at the right time. Too many notifications reduce the likelihood people will pay attention, and a release manager will have different levels of concerns, like promotions failing, than individual developers, who often need fast feedback on the impact of their work in cross-functional areas.

Q: Does Codesion offer Jenkins CI as part of their cloud service package?

A: Codesion currently does not offer a packages CI service. However, you can sign up with CloudBees Jenkins as a service. It works well with Codesion.

Q: For a small shop, which CloudBees Jenkins option is the most cost effective? E.g., is there a free option?

A: Of course! We offer a free level of service for everyone, so you can get your hands on all aspects of the CloudBees offering, try it out, and see how it works for you. You can upgrade to a paid subscription when you’re ready, or when you need a specific capability or quality of service. We also have a FOSS program that we have set up to help open source developers use the service for their projects.

Q: How do you address code security and confidentiality in the cloud?

A: CollabNet Cloud Services offer various solution for code security in the cloud. First, our data centers are SAS 70 Compliant, and all communications to our servers are via HTTPS. If customer has security requirements where their code cannot use a shared, mulch-tenanted infrastructure, then we can offer single tenancy where a customer’s code is stored on a dedicated server and not on a shared server. In addition, disk level encryption is also an option via our Enterprise Private hosting.

Q: I thought you guys would cover ALM software like ScrumworksPro or TeamForge. Could you provide some guidance on how to handle PBI and task dependencies?

A: ScrumWorksPro has tasks to PBI dependencies. TeamForge has even more flexible dependencies where any tracker item (defects, user story, tasks … etc) can have parent / child relationships with any other object. If you have specific scenarios that require help, please email support@codesion.com and we can answer, in more detail, the business solution that you are looking for.

Q: What is Jenkins vs. TeamForge? Is it competing software?

A: Jenkins is a Continuous Integration Server, TeamForge is a ALM (Application Lifecycle Management) platform that offers tracker, documents management, SCM, Wikis, Discussions, and other features for Collaborative Development. Therefore, they are complementary and not competitive. In fact, TeamForge has existing Jenkins Plugins that work seamlessly between TeamForge and Jenkins.

Q: Are there any plugins for Netbeans IDE? Is it possible to integrate CloudBees Jenkins with Netbeans?

A: Not today, sorry. We love NetBeans, but we do not have a plugin for it yet. You can use the CloudBees SDK quite easily alongside your NetBeans IDE to interact with the full CloudBees platform, though.

Q: Do you need to signup with codesion and cloudbees individually to use continuous integration and continuous deployment services?

A: No, that is why we partnered together. If you sign up with CloudBees, you can add Jenkins and Codesion together without having to signup separately.

Q: Do you plan to integrate Gerrit (or other code review tools) with Git?

A: Within the next few months, TeamForge will have integration with Git and Gerrit for code review. This will be available for on-premise or Enterprise private hosting of TeamForge. However, this will not be available for Codesion TeamForge project in the public cloud.

Q: What’s the Eclipse plugin we need to have?

A: You can find it in the Eclipse Marketplace. From Eclipse, look under Help -> Eclipse Marketplace, and search for “cloudbees” to locate the CloudBees Toolkit for Eclipse.

Q: How do you automate your CI from a source code repository like Git or SVN? How do you configure it in Jenkins basically?

A: Like all-things-Jenkins, a good place to start is the Jenkins Update Center console. Starting at the top-level, you choose “Manage Jenkins”. From there you can choose “Manage Plugins”. There are many plugins for source code control systems such as SVN, Git, GitHub, Perforce, and TeamForge, grouped under “External Site/Tool Integrations”. When you install a plugin, additional configuration UI specific to that plugin is made available within the “Manage Jenkins” screen.

Feel free to email us at cbu_sales@collab.net if you have any questions or comments.

Enterprise Cloud Development: Beyond Shadow IT

hrmpw — Wed, 22 Feb 2012 07:00:05 -0800

Hosted version control providers have been around as long as Subversion and Git. CollabNet released the first version of Subversion in 2000 while Git first appeared in 2005. CollabNet’s Codesion (nee CVSDude) started out as a server in a bedroom in 2002 and weren’t the first or only kids on the block. Today, a quick Google search for “hosted version control” yields over 29 million results. Obviously, there aren’t 29 million providers out there but it is a topic of much discussion and debate.

To date, most of the users of cloud-based version control have had little or no IT support and have fallen into one of several categories: open source development, start-ups/SMBs, or shadow IT projects, but I think this is starting to change. We are reaching an inflection point where Enterprise Development in the Cloud is increasingly becoming not only viable but attractive.

The internet has been a boon to developer collaboration and open source projects. With sites like StackOverflow, SourceForge, Gitorious and many more, developers are able to share ideas, share code, ask questions, etc. Likewise, start ups and SMB’s run pretty lean these days. Gone are the heady days of dot com funding, replaced by fiscal responsibility. The cloud (IaaS, Paas, SaaS) has supplanted the need for expensive infrastructure. It is this last category of cloud developers (Shadow IT projects), though, that is shaping this movement towards Enterprise development in the cloud.

To explain why I think this is the case, we need to go back 10 years and look at the IT and internet landscape when SalesForce.com (SFDC) arrived on the scene. Today, SalesForce is one of the great success stories of SaaS and the cloud in general, but 10 years ago many people doubted that SFDC and CRM in the cloud would ever succeed, let alone gain Enterprise adoption. I was a sales engineer at the time and I distinctly remember talking to other sales people and IT managers that scoffed at the idea storing something as important as sales contacts on the internet. How can they expect companies to put that kind of Intellectual Property (IP) on third-party servers? What we underestimated were the needs of distributed sales teams for a solution and the ability of SalesForce to overcome the IT objections regarding data security, data availability, and data portability (by portability I mean that the data isn’t stuck in the cloud).

At the time, sales teams had to choose between a centralized model like Siebel for all of their account information or a distributed model like ACT!. Not every enterprise had the time and resources to roll out a new global SFDC solution or upgrade existing systems to give both sales teams and sales managers the requisite account visibility. Even with a centralized SFDC application many field salespeople used their own contact management software from home or the hotel for day-to-day activities. The distributed model, on the other hand, was already available to everyone and gave distributed salespeople full control of their accounts, leaving sales managers with almost no account visibility. In either case precious account information was kept unprotected on laptops. Neither of these models fully met the needs of sales reps, sales management, or IT.

SFDC and CRM might have trudged along in this path of enterprise application integration (EAI) and modernization for many years if not for two things. First, VP’s of Sales aren’t typically the type of people to sit idly by when IT tells them they will have to just wait for a better solution like every other department. Second, SalesForce was out in the market generating buzz. By no means was it a perfect solution but it did hold enough promise that impatient Sales VP’s gave it a chance; with or without the blessing of IT.

‘Shadow IT’ approaches a problem with the assumption that it is better to ask for forgiveness than permission. The tipping point comes when it is time to ask for forgiveness; a solution either becomes blessed by IT or it is forcefully abandoned. In the case of SalesForce, when it came time for the sales team to defend their actions they were prepared. They showed that they were more efficient as a team; managers had visibility into the accounts and could create accurate funnels; and sales reps had easy access at home, the office, or at a hotel. For their own part SalesForce ensured that the customer data was available, portable, and secure. Without a comparable alternative of their own to offer right away and their major objections answered, IT begrudgingly began to accept having corporate data off-site.

Does that mean every enterprise application will suddenly move to the public cloud? Doubtful, but I think it does show that a compelling business case combined with an enterprise-ready SaaS platform can be successful. Sales teams had a compelling business need for a better solution and the will to look externally. SalesForce provided an enterprise-ready SaaS platform that might not have gained the complete trust of every CIO but overcame enough objections and provided enough value that the Sales teams could not be overruled.

So, how does that relate to development in the cloud? Unlike Sales, Application Development has traditionally been a function of a business organization or a project but not a direct function of the enterprise. Development teams are, therefore, divided into project teams specific to an organization or department and left to their own devices with little or no standardization. This results in the use of different languages, platforms, databases, project management tools and source control management. Whereas Sales required a holistic, modernized enterprise solution and were given the choice to wait for one or look externally, development teams required a project or departmental level solution and they typically managed it on their own. Whether Subversion, Git, VSS, or CVS was selected it was up to each development team to manage their own code. Many teams ran their own server in-house and some chose a hosted, cloud solution.

Development teams have lived and died by Shadow IT for years, managing all of their development tools on their own, but that is starting to change. Cloud platforms such as Force.com, Google Apps, Joyent, Amazon, etc enable high-velocity business automation. The introduction of new PaaS and IaaS solutions for private clouds extend this ability for high-velocity application deployment to IT Ops as well. This, in-turn, drives a desire for faster and faster application development, increasing the focus on Agile practices, development standardization, developer collaboration, code sharing, and DevOps (continuous integration and continuous deployment). Rapid application development has become a requirement across the enterprise and Shadow IT alone can no longer support these initiatives. It is no longer feasible to waste developer time managing servers and supporting tools. Teams that used to be independent now require a common, collaborative platform for their development tools and project management.

Development teams today are finding themselves in the exact same position that sales teams were in 10 years ago. They can no longer meet the demands of the enterprise by managing their own tools and are looking to IT for an enterprise solution. Like the sales teams before them, rather than sitting idly by waiting for an infrastructure and solution to be purpose-built for them more and more development teams are finding a ready-made solution in the cloud. Sales teams paved the way for the acceptance of business IP in the cloud and development teams are following.

Companies looking for an enterprise development solution are exploring the cloud and they are asking the exact same questions that were once asked of SalesForce: What are your security standards? (Are you PCI compliant?) What are your data portability standards? (How easily can I backup my data from the cloud?) What are your availability standards? (Do you have a disaster recovery plan in place?) Now that IT can be given satisfactory answers to these questions there is absolutely no reason to think enterprise development in the cloud will not be as important or ubiquitous as SFDC and CRM in the cloud.

Subversion 1.7.2 is now available!

nbellcollab — Tue, 21 Feb 2012 09:16:17 -0800

Over the last few weeks we have rolled out Subversion 1.7.2 to all our servers. Subversion 1.7 delivers most notably, enhanced performance plus new and improved features and important bug fixes. If you are interested in all the changes, I encourage you to read the change log or here are some other great resources to help you learn more:

Video: What’s New in Subversion 1.7 (New Features & Functionality)
Webinar Replay: Subversion 1.7 - Why You Should Care (Presenters: Bob Jenkins & Mike Pilato)
Subversion 1.7 Q&A (from the CollabNet SVNblog)
- Part 1
- Part 2
- Part 3
- Part 4

Although you can use your 1.6.x client with Subversion 1.7.x, we recommend you use 1.7.x clients to access your repositories to use some of the new 1.7.x features.

Enjoy the enhancements

You Ask, We Answer! 10 Commonly Asked Questions...

hrmpw — Fri, 20 Jan 2012 17:01:33 -0800

Here at Codesion our customers come from a variety of backgrounds. We have expert users that have been running CVS for years, we have Subversion users that have been using it since it was first introduced, we have users that are transitioning from Subversion to Git, and we have many new users that have never used version control With so many levels of expertise, the questions we see on a daily basis run the gamut. Here is a sampling of some of the more recent questions and answers.

Q: What types of files can you store? (e.g. video, files, HTML, .NET, etc..)

A: In short, everything. Any files that you want to version or work on collaboratively can be stored in Codesion. Subversion and Git are file-type agnostic so you can work with text-based source files or with binary files (graphics, videos, etc). If you have a client that can interface with SVN or Git you can work with any files. Click here to read a great blog article discussing how people are using Subversion as version control and storage for many things other than just source code.

Q: What type of backup support does Codesion offer?

A: Our backup system is designed on the philosophy that the customer always owns their data. We make sure their data is always available, secure, and backed up but we also make all of those backups available to our customers.

You can read more about our backup procedure here. We do a hot backup to a dedicated server every 10 minutes, a cold backup to a dedicated datacenter every 24 hours, and we maintain an archive of those cold backups for 30 days; 10/24/30. The likelihood of data loss is very, very slim.

Once we have those backups, we don’t just sit on them, we make them fully available to our Business Plan customers both on demand and through a push mechanism. Customers can go to the Backup tab in their dashboard and either download their backups directly from there or schedule a service for us to push their backups to them via svnsync, rsync, ftp, sftp, or WebDAV. Customers always have the option of maintaining their own data backups.

Q: I need my issue tracker to interface with my source management. I don’t want to be in one application and then have to go to another application to log a fix. How can I do this?

A: Ticket integration is one of the most popular features in Codesion. The Codesion community article describing how to link your repository to your issue tracker is consistently one of the most viewed articles on our site. All commits into SVN, Git, and CVS can update tickets in any of our hosted products: TeamForge, Scrumworks Pro, Bugzilla, and Trac. We also support ticket integrations into third-party issue trackers such as Basecamp, Jira, Rally, VersionOne, etc.

Q: How can I setup RBAC (role based access control) on Git like I can on subversion?

A: One of the great features of Subversion is the ability to apply very specific user roles to different directories. For example, you can give a specific team R/W access to a particular branch in the project but no access or read-only to other branches or the trunk. This gives the project administrator full control of their repositories.

Git, on the other hand, is a Distributed Version Control System (DVCS) and it is meant to be shared. Whenever I think about the Git sharing model I can’t help but think of the lyrics from “Games without Frontiers” by Peter Gabriel:

Hans clones from Lotte, Lotte clones from Jane
Jane pushes to Willie, Willie is happy again.

Git is great for moving code from remote to remote but it doesn’t support the same centralized access model that Subversion will. With so many clones and branches in different locations, how do you manage one repository that is used for builds and deployment? How do you make it so only a few select people can merge changes into the repository?

VP of Engineering Willie Wang, wrote a blog article about the need for a canonical, blessed repository in Git. This repository is used for all new clones (canonical) and for builds (blessed). Within Codesion, each Git repository can be kept in a different Project. Within the Security settings only specific users or roles are granted full R/W access to the blessed repository. Other users can be given read access so they can clone the repository but they cannot push any changes back into it. Users without write access to the blessed repository can work within separate Codesion projects with clones of the repository. The owner of the blessed repository can then manage which branches to merge back to the blessed repository. This Git push from one project to another can now be done from the Codesion Publisher as well.

Q: Do you report on how issues are being logged? I need to be able to get statistics out of issue tracking to see what programs are causing the most issues or are being updated.

A: TeamForge, Trac, and Bugzilla all have varying levels of Reports that can show where the most issues are being logged. ScrumWorks Pro and TeamForge also have Burndown charts and detailed reports to show how the team is tracking against the Sprint Plan.

TeamForge on Codesion, unlike Trac and Bugzilla, also has visibility across multiple projects so you can monitor all of these projects from a single dashboard.

Q: With remote servers, how do I know my performance will be acceptable?

A: Performance is not solely defined bynetwork speed. It is also contingent upon the resources available, the distribution of the team, and the reliability of the server. Many people moving their SCM into the Cloud are transitioning from a Subversion server under-the-desk or have a distributed team. In the case of the server under-the-desk, Subversion is going to be resource restricted or competing with all other services running on the server. With a distributed team, the users will have to access the repository over HTTP/s and someone will have to manage the firewall access and optimize network bandwidth.

The Codesion Platform is designed from the ground up to be secure, fast and available. We make sure that only you and your users have access to those servers. We make sure that your repositories are run on hardware optimized and dedicated for the service it is running, whether it be Subversion, Git, CVS, TeamForge, etc. Lastly, we make sure our servers are always available with a high-availability infrastructure, full backups and full system monitoring.

Q: Do you have workflow? I need to have management sign off on things moving to production — with notifications to staff who need to know.

A: TeamForge, Trac, and even Bugzilla all have ticket workflows built in and allow for varying levels of customized workflow. TeamForge, for instance, allows the user to create different workflows for each type of artifact tracked in the project. By default, TeamForge includes Trackers for: Defects, Epics, Stories, Tasks, and Tests. Each of these artifact types can have a different workflow and notification process. In addition, users can create their own custom Trackers and apply a new workflow to that Tracker. The level of customization allows for almost any scenario.

Q: What is the difference between SWP and TFP?

A: TeamForge Project (TFP) focuses on Application Lifecycle Management (ALM) while ScrumWorks Pro (SWP) focuses on Agile Project Management. Okay, but what does that mean?

Both of them allow you to capture product backlog items (PBIs) and plan Sprints. Both of them allow you to report your Sprint and Release progress with Burndown charts or custom reports. In short, both TFP and SWP are designed to improve the agility of your development team and to increase collaboration. The difference is in what you want to accomplish.

TFP also includes a full wiki for information sharing, document storage and versioning, defect tracking for change control, release management, and integration with Hudson for continuous integration. TeamForge is designed to manage the full lifecycle of your products from inception through sunset. It helps to standardize practices and keep everyone on the team informed so they can perform at an optimal level. Everything the project team needs is in one location.

ScrumWorks Pro on the other hand provides a laser-like focus on the process of Scrum project management. It is meant to let a scrum team practice scrum as efficiently as possible. Product Backlog management is very simple and straightforward while a virtual whiteboard is provided for collaborative task management.

If your goal is to manage all aspects of your development process and begin to standardize across products then TeamForge is probably the better solution. If your goal is to accelerate the adoption of Scrum within your development team or to increase the velocity of an existing Agile team then ScrumWorks Pro is probably the better solution.

Q: Why do you have multiple clients for ScrumWorks Pro (SWP)?

A: SWP has two clients: a Desktop Client and a Web Client. The Desktop Client is a Java Web Start Program that connects to the remote database hosted by Codesion over HTTP. The Web Client is an HTML client that connects to the same remote database hosted by Codesion. They are kept separate based on a division of labor.

The purpose of the Desktop Client is to provide a more robust client to simplify the project management tasks of Scrum. This includes Sprint Team user management, Product Backlog Item (PBI) management, Release and Sprint Planning.

The Web Client is designed as a lightweight client for day-to-day sprint team activities: task creation, task board, impediment tracking, and Burndown reporting.

The goal should be to have your Product Owner and ScrumMaster work within the Desktop Client, while the rest of the sprint team only has to operate in the Web Client.

Q: When should I use Git or SVN for my project?

A: Git versus Subversion has become a hot topic and many people have strong opinions one way or another. Many developers like the ease of use and flexibility of Git while others like the centralized control of Subversion. For us, the answer is simple: use whatever one makes you happy. I highly recommend reading this blog which provides a detailed viewpoint of the strengths and weakness of each between both version control systems.

Subversion or Git? Decisions, decisions ….

jrepenning — Wed, 11 Jan 2012 15:42:00 -0800

Are you facing a difficult choice between version control systems? Are you having trouble sorting out the alternatives? Are you bewildered by all the opinions you find on Google? Let’s see if I can help sort this all out.

CollabNet (the original stewards of the Subversion project) provides both Subversion and Git, either through our enterprise TeamForge product or through our Codesion Cloud Services. We think there’s a place in the universe for each. Here’s how to find yourself in that universe.

The short form

Here are some specific recommendations. If you want to stop reading at the end of this section, you should make out just fine.

If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.

If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree).

Neither of those? Take your pick, you should be fine with either tool.

The Basics

What do you want from your version control system? A lot of this is the same for everyone, and both tools accomplish these tasks just fine. If all you care about is the basics, you could easily just flip a coin and get on with your work, confident that your choice would be sound. These “basics” include:

Store all versions of your files (“version control”)
Associate versions of each file with appropriate versions of all other files (“configuration management”)
Allow many people to work on the same files, toward a common goal or release (“concurrency”)
Allow groups of people to work on substantially the same files, but each group towards its own goal or release (“branching”)
Recover, at any time, a coherent configuration of file versions that correspond to some goal or release, either for investigation or extension like bug fixing (“release management”)

Both systems do all these things quite well. If these things are truly all you care about … flip that coin! All the discussion and decision has to do with other details, details that are always secondary to the basics, but can become crucial to particular projects or environments.

So, if you haven’t flipped that coin and gone away, let’s look at the differences.

But first, some demythologization

Here are a few things you may have heard that just aren’t true, or aren’t true any longer:

~~Git hates windows~~. No, it doesn’t. It used to, but now there are good Git integrations with Windows Explorer (TortoiseGIT, SmartGIT) and most of the major IDEs (Visual Studio, Eclipse, Netbeans), and you no longer need to use the Unix emulation environment Cygwin.

~~Git is only for hackers~~. As a Unix-centric, command-line only tool, Git was originally anathema for many workers. But with all the GUI integrations, it’s considerably more friendly, within reach of nearly everyone (see Windows integrations above, plus non-Windows tools like GitX, Coda via GitX or Tower, Emacs).

~~Git is hard to learn~~. Well, it’s a lot easier to learn now, anyway, thanks to those GUIs, and to improvements in the command-line UI and documentation.

On the other hand

~~Subversion is slow on Windows~~. The latest Subversion releases, up to the current 1.7, have made great strides in Windows performance.

~~Subversion merging is hard~~. Well, it’s a lot easier now, anyway, thanks to the continuing progress on “merge tracking.”

So, what’s different?

As you’ve surely heard, the key difference is that Subversion is “centralized,” while Git is “distributed.” You can go many other places to learn about what that means in their implementation, I don’t spend time on that here. But I will talk about why it matters to you.

Local versioning

Git’s distributed model means that you have full version control operations purely locally on your workstation. Of course, the changes you make locally are not visible to anyone else, until you do something else (Git’s “push” or “pull”), but you can check changes in so they’re not lost, create branches, merge among branches, back up to older versions, and browse and compare versions — all without a network. The one cost in all that is, you have to learn some additional commands (push, pull, clone) and workflows, if you ever expect anyone else to see your work. You can do everything locally that any version control system can do … and you also have extra steps required to make your work visible to others, kind of an inescapable trade-off. On balance, local versioning is a significant convenience for the developer, and a big part of the popularity of Git.

Guaranteed centralization

Most processes have some reason to want one copy of everything, somewhere, that’s reliably known to be “the official version.” With Subversion, that’s the central repository. With Git, that’s … some repository or other: the tool doesn’t privilege any one repository over another, but users and conventions can. With Git, you have to remember to push or pull all changes into the designated central repository — not hard to remember, especially if you support it with other conventions, such as only building releases from the central, but still an extra step. With Subversion, there’s nothing to remember or agree to: there is only one repository. By definition, anything that’s checked in at all is checked in to the central. One place where this can become particularly important is in “governance,” where external constraints like Sarbanes-Oxley or escrow contracts demand hands-off guarantees. On balance, enterprises with governance constraints value the guarantees of Subversion.

(Governance, traceability, ALM, and DevOps all require broader support than just the code and files, of course: there has to be integration among the code repository, the tests, the deployed product, and the tracking system. Fortunately, CollabNet now integrates both Subversion and Git with these other components.)

Throw-away work

Somewhat paradoxically, there are times when you want to throw away (or keep private) some work. Git is better at throwing things away than Subversion is: you keep the potentially throw-away work in its own repository until you decide whether to make it official. If you decide to toss it, there are virtually no left-overs in the repositories you keep. By contrast, in Subversion, everything goes into the one central repository, and you don’t have that same option. Typically in Subversion, you don’t actually “throw away” such work, but only leave it on some branch you never look at. But it’s still there, taking up space, and possibly cluttering the history browser. The possibility of throw-away work is a fairly big consideration in open-source work (and in fact it was one of the key design considerations for Git), but rather less so for enterprise work (where throw-away work is also throw-away salaries, equipment, lighting, and all the other employee expenses), so enterprises typically avoid ever doing it in the first place. I wrote about handling throw-away work at some length a while back.

Un-recommendations

Some things are possible, but I wouldn’t recommend them — at least, not to someone who has to ask:

~~Git-SVN~~. Git is able to pull files out of a Subversion repository, store them in a Git repository (allowing all that local version control, and some inter-git-repository push/pull/merge), and then push the results back into Subversion. It sounds like the best of both worlds, doesn’t it? But you end up having to be an above-average expert in both systems, and parts of the workflow are very slow. Some folks really like it. Maybe you would, too. But it’s not what you’d call “mainstream.”

~~Cygwin.~~ Cygwin is a system for providing a lot of Unix-like capabilities on a Windows system. Early Git Windows implementations ran inside Cygwin. Again, this ends up forcing you to be an above-average expert in two very different systems. If you’re already steeped in Unix and Windows both, it can be handy. But it’s a high price to pay for just adding a little Git. Fortunately, Git Windows installation no longer requires Cygwin.

So, which one’s for you? Try a free, fully functional 30 day trial of Subversion and Git on Codesion to help make this choice.

Collaboration in the Cloud

nbellcollab — Wed, 04 Jan 2012 10:33:00 -0800

In a recent interview our VP/GM, Guy Marion (@guy_marion), spoke with IT Business Edge blogger, Arthur Cole, on the collaborative nature of the cloud. The flexibility and agility that the cloud provides plus the desire (I would go as far as saying ‘need’) to adopt collaboration and social networking work processes that we have all become to depend on in our personal lives, is driving more enterprises and development teams to push services and infrastructure to the cloud. This however does not come without challenges to the the enterprise though (Security, compliance, visibility etc)

Read the full interview here and what Guy has to say on “Collaboration in the Cloud”

Technical Debt - The High Cost of Future Change

hrmpw — Wed, 21 Dec 2011 16:59:00 -0800

But little Mouse, you are not alone,

In proving foresight may be vain:

The best laid schemes of mice and men

Go often askew,

And leave us nothing but grief and pain,

For promised joy!

Robert Burns wrote this verse of “To a Mouse” in 1785 and his words are just as true today. Foresight is not a perfect tool so we aren’t capable of creating a perfect plan for the future. Even if we spend months researching there will always be known-knowns, known-unknowns, and unknown-unknowns to account for in our planning.

Things that we know to be true today can always change in the future. Anyone who has finished (or, I should say, started) a software release of any size knows that requirements are not constant. Business needs to constantly adapt to stay current with the marketplace. Business software follows the requirements of the business and must change just as rapidly. Software that forces the business to adapt to it rather than adapting to the business finds its way to shelf quickly.

In addition to ever changing requirements we have to consider the ephemeral nature of technology itself. Will our state-of-the-art technology still be cutting edge by the time we finish? Is the technology stack too old or too young? Too old and it might perform poorly or require expensive refactoring later. Too young and it might be unstable and poorly supported, especially in a partner ecosystem.

Those are just the things we think we know. Most of us who survive high school realize at some point that we don’t know everything. In fact, there is quite a bit that we don’t know – I feel dumber every year. However, even in this great pool of ignorance there are things we know we don’t know. The rest are things we never even considered. On every project I have been part of I have always gone in knowing all the questions I didn’t have answers to yet. Likewise, on every project I have worked on we have come across problems that we never even considered when we started.

As an example, a few years ago I bought a wooden sailboat to rebuild. I researched and I schemed for months on ways to save my nice teak deck. Finally, I decided that I couldn’t save the deck because the plywood substrate was just too rotten; I would have to rebuild the deck.

I knew my budget, I knew my meager carpentry skills, and I knew what I wanted as a finished product. I thought I had an achievable plan. At the same time, I knew that I didn’t fully know the state of the frame under the deck and some of it might have to be rebuilt. What I never considered and didn’t know until I removed the deck was that my steering quadrant was rusted and needed to be completely abraded, rustproofed, and repainted. I also didn’t know that the plywood substrate under my deck extended under my bulwarks (the section of hull that rises above the deck) compounding the rot problem by an order of magnitude.

In this case, my unknown unknowns (the things I didn’t know and never thought to ask) put the project well beyond my time projections. While it’s true that more research and planning up-front might have revealed these problems before I started, it would not have changed the work needed to get the boat ship-shape again and I would have started even later. At this point I was faced with the choice of cutting corners - possibly compromising the future safety of the boat - to get something done before rainy season started or stick with my plan and finish much later than I wanted. I was facing Technical Debt.

While Technical Debt can occur in a boat-rebuilding folly such as mine it is more commonly associated with software development. When we begin a new software project we are typically given a list of feature requirements and a release time frame. This intersection of features and time is usually based on an ideal development project. As the known-knowns change, the known-unknowns crystallize, and the unknown-unknowns manifest the ability of the team to meet the original goals is compromised.

In the case of my boat the debt resulted in a long delay in using it. If I had cut corners to finish the work in one season the cost of future repairs would have been much greater, assuming future changes were even possible. Software development teams don’t have the luxury of delaying a release indefinitely; something has to be shipped. When faced with missed deadlines most software teams go into Technical Debt. The release sometimes takes precedence over good development practices: features are dropped, tests are skipped, and extensibility is sacrificed. The future cost of paying back this Technical Debt through refactoring, creating new features, or updating the technology stack is often overlooked.

Adopting Agile development practices is a great way to combat this mounting Technical Debt. Rather than go into the details I highly recommend watching the webinar hosted by Certified Scrum Trainer Michael James. He chronicles several examples of Technical Debt and discusses how best to use Agile development practices, specifically Scrum, to lessen the occurrence of future debt and incrementally pay back accrued debt.

Another factor in reducing Technical Debt is to make sure that the required tools and the correct tools are always available to everyone on the team. “Mise en place” is a French phrase used in culinary schools that means “everything in place.” Chefs are drilled in the practice of preparing their stations before beginning work so they can quickly deliver high-quality products on a consistent basis.

Agile development teams should approach projects with this same discipline of “mise en place.” Developers don’t need just an IDE; they also need access to collaborative tools such as version control, issue tracking, file storage, and agile management. Having these tools available and ready-to-go when the project starts enables agility. Rather than devoting resources to installing, maintaining, and supporting all of these tools separately more and more teams are turning to the Cloud to properly equip their development team with all of the tools they need.

This is why Agile software development and the Cloud make such a powerful combination. The methodology is designed to make the team as efficient as possible and the platform is designed to deliver the requisite tools in a highly available, scalable and secure format. The two together can significantly reduce Technical Debt and lower the overall cost of delivering high-quality products in a timely fashion.

Codesion Brings Git to the Enterprise Cloud

copello0 — Wed, 14 Dec 2011 07:10:00 -0800

Although Codesion has been mainly associated with providing Enterprise Grade Cloud Hosting of Subversion, we are not a Subversion only company. Our philosophy has always been to provide the best of breed tools to help developers get things done. Therefore, I am happy to announce that our Git Hosting product is now generally available (GA).

Ultimately, Codesion believes you, the developer, should have a choice on tools that best suit your mode of development. Now, it is obvious that Codesion won’t be able to provide all the available open source development tools in the Cloud, but we want to provide the most popular ones. The reason for this philosophy is that each organization and developer has different needs. For example, an organization may be familiar with centralized development model with a single trunk, with minimal need for branching or complicated merging. In addition, this organization also needs a lightweight project management tool. In this case, SVN + Trac are perfect tools for this organization. However, we also know that many of you want to develop in a more distributed model. This is where a DVCS like Git becomes useful. The speed, ease of branching and merging becomes important. We want to make sure that we support both, and support both well.

When you consider DVCS development workflows using Git in the context of mission critical development, I believe Codesion Git, now GA, is a smart choice. In a business, it is important to define your blessed repository. No matter how distributed your development workflow is, at some point, a defined, canonical blessed repository is important. This is the source repository that you will deploy to production. This is the repository where all approved code will be merged. This is the repository your developers will perform their initial clone. This is the repository that you should put on Codesion Git.

Why should the blessed repository reside in Codesion?

Codesion provides 99.9% uptime guarantee, and is one of the most reliable cloud providers of source control. We have the numbers to prove it. While Git was in beta, from May 2010 until December 2011, the cumulative uptime in that period is 99.98%. This is one of the most important metrics for a business doing mission critical development. We now have implemented a high availability architecture to insure that we can continue to stand behind 99.9% guarantee.

Enterprise Backup. Many argue that because Git allows a developer to clone the whole repository, you don’t need to have backup. If you have 5 developers, then essentially you have 5 backups because they would have cloned the Git repo locally. I disagree with this. If your blessed repository went down and no longer available, by using the above backup method, you will pick one of the five developer local repos and make that the blessed repository. Would you want to do that? That repo may have changes that are not ready for production. Therefore, you will need to scrub through the repo before it is ready to be the blessed repo. Instead, Codesion performs a multi-layer backup of your blessed repo for you. Our hot backup system backups up your Git repo regularly during the day, several times in an hour. We then have a cold backup system, in a separate data center, that contains your daily blessed repository backup. This insures that you can restore from backups of your blessed repo, not from a repo that is locally residing on your developer machine.

Enterprise Security. Codesion Git provides secure access from both HTTPS and SSH. In addition, you can configure your Git permissions and other services within Codesion via a single unified interface. If you were to host your own Git and Trac, you would have to configure permission separately within each of those applications. With Codesion, you create a developer role that encompasses permissions for both Git and Trac. Our security system then synchronizes the permission down to Git and Trac.

Integrations to Project Management Systems. With Codesion Git, we offer integration to ScrumWorks Pro, TeamForge Project, JIRA, Pivotal Tracker, Trac…and other project management systems. When you perform a push to your Codesion Git repository, you can associate the push to a specific backlog item or defect.

I have just highlighted several key benefits of using Codesion Git hosting as your blessed repository. There are many other features like notification, activity feed reporting, web hooks, ticket integration, and others that I did not speak of in-depth.

Finally, Codesion offers both open source and commercial grade Agile tools all under one roof. You pay one bill, select the number of users that you need, grow your plan on an as needed basis, and have access to a variety of SCM tools (git, svn, cvs), Issue Tracking (Trac, Bugzilla), Agile Project Management (ScrumWorks Pro), and Application Lifecycle Management (TeamForge project). You can start simple with just Git, add Agile Management, and grow to ALM with the same trusted Cloud Development provider.

Try Codesion Git Hosting out FREE for 30 days and let us know what you think.

Interview with Vinay Asthan, VETS, Inc. about being Agile and using ScrumWorks Pro in the Codesion Cloud

nbellcollab — Thu, 17 Nov 2011 06:45:00 -0800

Today we are very pleased to share with you that ScrumWorks Pro (SWP) in the Codesion Cloud is no longer in beta and is now generally available and fully supported. (Read the Press Release here) Congratulations to the Codesion Engineering Dudes on another fine effort and display of brilliant engineering. A big thanks to all the beta customers who provided some great testing and feedback to help us deliver SWP GA. ScrumWorks Pro is now included in our Agile Business and Agile Enterprise plans or Try it FREE for 30 days.

We are also really happy to share with you some insight into one of our customers Agilepracticing customers who uses ScrumWorks Pro, Vinay Asthan from Veterans Enterprise Technology Solutions, Inc., who was an early adopter of ScrumWorks Pro in the Codesion Cloud.

Codesion: What is your role at Veterans Enterprise Technology Solutions?

VA: I am working as a Technical Lead for the Veterans ChampVA ESI project.

Codesion: How many people are there in your development team?

VA: Vets Development teams have over 100+ members, my team is a team of 15 members. I have divided the team into two teams. First team is 8 members, and the second team has 7 members. I am the Scrum Master on both the teams

Codesion: What kind of development projects are you responsible for?

VA: Vets, Inc. is involved in developing applications supporting Veterans Affairs. The Applications vary from Complete solutions, to developing the Front End or Back End Processing

Codesion: What development methodologies do you practice?

VA: Vets has implemented Scrum for the ChampVA ESI application development.

Codesion: How long have you been practicing Agile for? How mature are your Agile practices?

VA: I have been practicing Agile since 2008. I think my Agile/Scrum practice is pretty mature. I am a Certified Scrum Master.

Codesion: What differences have you noticed since adopting Agile practices?

VA: Better team communications and goal oriented efforts – resulting in better productivity.

Codesion: What are your goals for your team when it comes to Agile for the next 12 months?

VA: We are planning to complete two product increments (6 months each) in the coming 12 months. We are just getting started.

Codesion: Why did you choose ScrumWorks Pro on Codesion as your Agile project management solution?

VA: It started out when I was looking for a team collaboration tool for the team following Scrum. I tried the trial version of Codesion, and it seemed like a perfect fit. The team is happy using the tool, as it is very easy to use. The product owner is happy as they get to see the progress by the team.

Codesion: What other products did you compare with ScrumWorks Pro?

VA: VersionOne and Microsoft Team Foundation Server.

Codesion: What recommendations would you make to your industry peers when looking for an Agile project management solution?

VA: I will highly recommend Codesion, as Scrumworks is a great tool to manage any Scrum, including multiple teams – very easy to use. Additionally, Codesion also provides access to Bugzilla, a nice defect tracking system. Pricing model is also just right, fits our and most small and mid-size businesses. It does not break the bank with the subscription based model.

Codesion: What other applications/services are you using or plan to use on the Codesion Cloud Platform?

VA: Bugzilla, and probably SVN.

Codesion: Thanks Vinay for sharing and happy Scrumming!

Learn more about ScrumWorks Pro on Codesion here.

Monthly Uptime Report Now Available!

tonamedina — Wed, 16 Nov 2011 18:24:00 -0800

One of Codesion’s main strengths is undoubtedly Uptime.

Yes, servers in general do love to go down, and, yes, Codesion is not exempt to this. That being said, even when our services might be temporary down, and while we quickly capture it in our status page, we are proud of the excellent job our SysAdmins do to consistently keep our 99.9% SLA for our Business plan users.

In that regard we came to one conclusion: “If this is one of our main strengths, why not make our Uptime report available to all our users to see?” And so we have.

As part of our recent initiatives for our Customer Success program, and increasing our Business transparency, you can now come to ONE place to get an accurate gauge on how Codesion services are really doing lately.

Where can you find this Uptime Report?

Easy… In our status page too (BTW we encourage you to subscribe for updates by entering your email there).

Simply visit our status page, and click on our Monthly Uptime Report Page:

How good is Codesion supposed to be doing?

If you are on our Business plans (or above), we are required to comply with our High Availability offering that entitles you to a 99.9% uptime.

If you have only a Personal plan (formerly known as Team Edition), we do not have an SLA in place. If you are doing mission critical development, and must have an SLA in place, please consider upgrading to a Business plan.

If you have any questions, please send us an email.

Cheers!
Tona
Your Friendly Customer Success Manager
Codesion - CollabNet Cloud Service

300!!!

socollabnet — Mon, 31 Oct 2011 17:38:00 -0700

In addition to Codesion’s thousands of Personal Plan customers, we are eager to announce that the Codesion Cloud Business won its 300th Professional Edition (now named “Business”) customer. Given that we only announced our 200th Professional Edition customer in April of this year, taking only half the amount of time to reach this milestone, it’s terrific to see the accelerating momentum in the market for Enterprise-grade, cloud hosted developer solutions.

In 2009, Codesion (known as CVS Dude) focused on providing the best Subversion and Git hosting services to our Personal Plan users. Thanks to customers’ requests, we created Business Plans with enhanced features and benefits to support the growing Enterprise market. Customers can benefit from a complete OS developer suite (SVN & Git integrated with Trac and Bugzilla), collaboration tools like TeamForge, daily backups, and 24x7x365 support. In addition, we released the ScrumWorks Pro Beta integration in September of this year, providing customers an Agile Project Management solution.

As we leave October and surpass our 300th customer, it’s important to recognize the hard efforts of our Codesion Business Unit team. Their unequivocal dedication to providing the leading Enterprise-grade Subversion, Git and CVS hosting services is what makes each day an exciting one. Stay tuned as we are soon to announce the GA release of our Agile Project Management solution, ScrumWorks Pro, and our new Git enhancements.

Another new GIT feature: GIT External Integration

nbellcollab — Mon, 31 Oct 2011 16:03:44 -0700

Keep them coming! We are very pleased to have released another great new GIT feature, GIT External Integration. What this means is that GIT can now send commit messages and update statuses to your trackers including Trac, and other services. You no longer need to open up your trackers to update, close or append tickets.

The ability to be able to automatically send commit messages to your other services will save you some serious time. It’s available now. Go try it out and tell us what you think.

For more information and the correct syntax to use, check out this knowledge article

CollabNet Desktop for Outlook and your Teamforge in Codesion

tonamedina — Mon, 31 Oct 2011 15:53:00 -0700

Did you know that CollabNet offers an MS Outlook plugin to connect and use your Teamforge instance? This means users get more control for accessing their Teamforge artifacts right from within MS Outlook—a place where you might be already spending great deal of time.

So, if you are using Teamforge in CollabNet Cloud Services, and also using MS Outlook, please take a look at our article that walks you through the setup process.

Click here for more info on how to set this up…

New GIT feature: Commit Activity Feed

copello0 — Mon, 17 Oct 2011 11:58:00 -0700

Codesion customers have been asking us when git will exit out of beta…well, we have an answer for you. The Codesion team has been diligently iterating our Enterprise GA in order to go GA in Q4, 2011!

Thanks to our customers’ request, we released a new feature: bringing git commits as part of our activity feed. Make sure you configure your git configuration with your identity when installing git on your desktop. Doing this step ensures git activities are identifying you correctly:

git config —global user.name “your name”

git config —global user.email “youremail@email.com”

WEBINAR RECAP: Codesion ScrumWorks Pro Live Demo Replay

socollabnet — Thu, 13 Oct 2011 16:27:04 -0700

This week sales engineer Caleb Brown hosted the webinar, “Codesion ScrumWorks Pro Live Demo.” Caleb conducted a poll at the beginning of the webinar, asking attendees their top reason for attendance. The results showed that over 50% were interested in learning the general features of ScrumWorks Pro. If you missed the live session, you can watch the recording here.

Here’s a followup to the live audience questions.

Q: How easy is it to balance and redistribute workload between developers?

A: The Team Member Load report can aid with this task, showing each team member’s work load (including work being done across other projects). Re-balancing a workload is as simple as changing the Point Person on a task.

Q: We estimate our Stories in Ideal Days, does that work in ScrumWorks?

A: Any estimation scale works within ScrumWorks.

Q: We have a manager who insists on micromanaging our team, can we block him/her from seeing our tasks?

A: Roles and Permissions are often used to deny people in certain roles visibility to artifacts like Tasks, removing the tools necessary to micromanage.

Q: How should I show progress to my customer on major feature development(s)?

A: A variety of reports in ScrumWorks Pro can show this. Typically the Themes feature is used to tag the work done for a specific customer, then the reports are generated using Web Reports, filtered by that customer’s theme. The big benefit to reporting in this fashion is that the reports are dynamically updated so that the customer can view the status of their work in real time.

Q: Why do you have a desktop client? Isn’t that old technology?

A: The Desktop Client uses Java Web Start, which provides most of the Benefits of a Web Client in that you never need to update or install it, these things happen automatically. This technology allows for things that Web Clients just can’t do very well, such as Keyboard Shortcuts and Speedy Mass Updates. It also shortcuts many of the problems with Web Clients, such as add-ons and plug-ins that stop a web client from running. There are many reasons our existing customers do not wish us to deprecate the Desktop Client, and I expect it will stick around for a little while longer.

Q: How can billing be accomplished? My people are time and materials, hours towards deliverables matters.

A: Typically the “Hours Spent by Theme” report is used for this purpose. You can use it to select a date range and display the total hours spent on every backlog item tagged with that specific theme.

Q: Effort points and hours? Which drives the other? Do they automatically adjust each other, or do we need to update both.

A: Hours spent, hours remaining, and Effort Estimations are all completely separate from each other and are used for different metrics. Hours remaining feed into reports such as the sprint burn-down or the team member load report. Hours spent are typically used for billing purposes. The Effort Estimations are used for all reporting that crosses teams and sprints and when you measure the rate at which the teams complete the effort estimates (as velocity) form a basis for planning.

For those interesting in trialing ScrumWorks Pro, there’s a free 30 day trial of the tool on Codesion.com. Click here to find more information. Feel free to send us an email if you have any questions or or comments.