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
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?
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.
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
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 3rd 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
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.
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.
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.
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:
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
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.
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:
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:
On the other hand
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:
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.
Codesion offers code management in the cloud. Code. Connect. Deploy.
Just want the latest features? Subscribe to product updates.
