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.

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.

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”

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.

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.

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.

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

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.

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

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…