Related
I may be working with Siebel CRM soon, and I'm looking for advice on using modern development practices and enterprise best practices.
Specifically I'd like advice on the following areas:
How should we set up version control (specifically with Subversion)? What kind of structure should our repository have? How should we handle branches and tags?
How can we do code reviews? How can we peer review configuration changes made through Siebel Tools that don't necessarily have any "code"? We want to review these changes for quality assurance and knowledge transfer, as well as compliance with change management policies.
What sort of change management works well with Siebel? How do we verify that only things listed in our change log are actually changed when we do a new deploy?
How can we automate testing of our application? Is unit testing even possible with Siebel? I saw another question suggesting QTP for web testing, but are there other options that work?
Are there other things we can do to implement Continuous Integration practices with our Siebel development efforts?
What recommendations do you have for naming conventions and other things that would traditionally fall under "coding style" guidelines?
How should we separate development roles from Siebel Administrator roles? What should our build/test/deploy cycle look like?
It's not likely that I'll be able to obtain any new expensive tools for this, but if there's a paid tool that provides really great ROI, feel free to mention it.
If you have other recommendations along these lines, but not specifically addressed by one of my questions, feel free to add that as well.
How should we set up version control (specifically with Subversion)?
use the guidance provided in the documentation for Siebel Tools. But please note that Siebel does not build from the files in SVN so it will only be useful as an archival tool; you cannot manage your code or build from SVN.
What kind of structure should our repository have? How should we handle branches and tags?
Siebel development code is not built or managed in SVN so this is a pretty useless thing to do. Just note the date that you built your SRF and exported your Repo and match with a tag or branch in SVN.
How can we do code reviews? How can we peer review configuration changes made through Siebel Tools that don't necessarily have any "code"? We want to review these changes for quality assurance and knowledge transfer, as well as compliance with change management policies.
Use Siebel Tools to do this. It has a built in 'checking' tool for obvious errors (all devs should be using this before they check in) and a diff tool (you will need to check against an older version of the same object - which you could drag out of SVN if you want). I normally automate the checking tool once a day and review the output logs, and automate build from the Siebel server 5 times a day and look for errors during the compile. Diffs via SVN and a standard diff tool might be possible, but the Siebel objects are stored as XML-like files in SVN and so are hard to read sometimes.
What sort of change management works well with Siebel? How do we verify that only things listed in our change log are actually changed when we do a new deploy?
?
How can we automate testing of our application? Is unit testing even possible with Siebel? I saw another question suggesting QTP for web testing, but are there other options that work?
QTP is the standard way to go - check on the Oracle web site for other vendors that they may recommend. You could also try Sikuli.
Are there other things we can do to implement Continuous Integration practices with our Siebel development efforts?
Not really.
What recommendations do you have for naming conventions and other things that would traditionally fall under "coding style" guidelines?
Checkout the appropriate section of Siebel Bookshelf for current naming guidelines and use these always.
How should we separate development roles from Siebel Administrator roles?
Not sure what you mean.
What should our build/test/deploy cycle look like?
Build a new SRF and export a new Repo from Dev once a night. Once all the dev work has been checked-in and unit tests are done take the next SRF and Repo and push into the test environment. At this point in normal software development you'd branch your SVN and continue to develop on the trunk but Siebel is different because you cannot build from SVN and you cannot easily restore a whole lot of files from SVN into your build environment, so you're best to make hot fixes for test either in dev (and pause mainline dev development until that is done) or in the test environment, and do ugly backports to the development environment (that's what most people do in fact). Build a new SRF and export a new Repo from Test once a night and once that's good, snap a copy for your Production release.
Try to stick to cycles of no more than 4 weeks (1 week for desing/prototyping. 1 week for dev, 1 week for test, 1 week for bug fixes and deployment) - any longer than that and the overhead of planning will become too great.
Hints for an easier life: Avoid eScript except in Business Services (otherwise it becomes unmanageable); use all the Siebel built-in tools instead of rolling-your own; try to avoid any roll-up functionality (it always seems like a good idea but it always destroys performance); keep the number of screens and views to an absolute minimum; do not build views when you should be building reports instead; always make sure that EIM tables match and schema extensions that you make - even if you don't use EIM right now; try to build Integration Objects to match your logical schema - they are always useful (for web services, XML publishing) and a hell of a job to build after the fact; prefer Workflow Policies over run-time Events; don't add new sort or search specifications without indexes - ever ever ever; don't make by-reference links to the LOV table; always patch; if the vendor doesn't say that you can do something, never do it.
We have set up a complete Continuous Integration toolchain for our Siebel systems consisting of Subversion, Hudson, Jira, Siebel ADM and some self-written stuff integrating everything.
This helepd a lot, although Siebel "source code" is not as suitable for standard CI approaches as, say, some Java-based project.
And, YES, it is possible to put your files - including SIF - into your Subversion repository and use this as source for your deployments.
I'm planning to blog about this in http://siebel-ci.blogspot.de/ - stay tuned.
SVN/CVS are not suitable for Siebel, a few reasons being
a) Siebel objects are db objects and SVN/CVS etc store sif equivalent of the changes.
These changes are impossible to query except for some basic queries.
b) The integration between Siebel tools and SVN is a loosely coupled integration.
The ideal integration should be with the Siebel repository and invidual tools.
Take a look at our tool Object Hive it addresses many of the short comings of a files based version control.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive has been from the ground up specifically for Siebel version control, some of its features are:
1) Object Based repository similar to Siebel repository that stores all version history.
This makes is very easy to query changes and conduct code reviews based on the changes
2) A browser based GUI that is similar to Siebel tools to query for version history (no combing sif files for changes).
3) Seamless integration - directly integrates with the Siebel repository.
No messy installation for invidual developer.
4) Powerful reporting (realtime and batch) to easily identify changes over any time period.
5) Oracle Exa-ready certified.
We are a small Microsoft shop with 4 developers. We like the idea to have everything integrated and under the same SQL database but not to deal with too many features or a complexity we don't need.
The other option would be to use two distinct third party tools. We also wonder if VS2010 version control and bug/issue tracking capabilities are comparable with the best third party tools on the market.
With TFS 2010, there is a TFS Basic version/configuration options. You can use SQL Server Express as the database, the install is simple and quick and you can install it on a client OS. It includes version system, work items and build system (no sharepoint, reporting...). Price should not be high, the target users for TFS Basic are those used to use SourceSafe. Also if you have MSDN, there is a change that it goes with it, so you would not have to pay extra.
Some thoughts on TFVC in general -- note that I've never used TFVC specifically, but I've been in a similar situation a couple times. My main concern is that it's too little.
TFVC (Team Foundation Version Control) appears to be a client-server version control system. I don't know anybody who hasn't upgraded to DVCS yet. I've never used TFVC but I can't imagine what benefits it'd offer to outweigh the architectural disadvantage. (And before you ask: I only use it from my workstation in the office, where the network has never gone down, but I still use its distributed features every day.)
I also work at a small Microsoft shop with 4 developers and we have never once regretted using Mercurial. It's one of the few decisions we made that everybody seems to have loved. It's one of those moves, like switching to a language with GC, that you never want to even think about reversing.
In terms of support, I hope you found some way to get great support from Microsoft. Things will come up with any VCS and it looks like community support is a couple orders of magnitude worse than Hg or Git.
I can't say much about bug trackers -- I think they're all pretty much the same these days. I've installed a couple open-source ones in an afternoon, even with no experience. The major difference seems to be, if you go with a big-name one, you'll be able to find lots of tools and extensions that work with it. For example, there are a million and one extensions for reporting/testing/etc. for Bugzilla. TFS probably has similar things, for enough money.
Two other things I'd keep in mind:
First, even if you only want these 2 features today, you will want other features in the future, and it will be (sooner or later) something Microsoft doesn't offer. So it's best to make peace with 3rd-party tools ASAP.
Second, unless you miraculously happen to pick the perfect set of tools for your company's future growth for all time, you will at some point want to migrate away from whatever solution you pick today. So make sure it either provides a way to do a full export, or is popular enough that other projects are falling over themselves to write importers for it.
I guess this all sounds kind of negative for TFS. I didn't really mean it that way -- I'm sure it does some things really well. But unless you're rolling in dough already, save your money.
Good luck with whatever you choose!
TFS work ittm tracking is awesome. Whatever your workflow is and the information you want to gather, you can do it easily with TFS.
Most expect TFS to do what they do out of the box as if it were omniscient. Unfortunately, you do things slightly differently than me and I from everyone else. The key is making it easy for the many different roles in your organization to get and input information into whatever your work tracking system is.
There is a plateau you will reach with custom, cobbled together tools that you won't get from cross referencing information along the product development process. TFS removes that barrier. The second barrier is knowing how to consume the information and that takes training and experience in effectively managing projects.
TFS Version control is certainly the low point when compared to the industry right now. DVCS popularity exploded about the time TFS came out. That said, Brian Harry has stated that TFS "fully expect that we will be adding distributed version control to TFS." http://blogs.msdn.com/bharry/archive/2010/01/27/codeplex-now-supports-mercurial.aspx
Take that as you will.
TFS is a great system but after having deployed and used it for some time I realize that the TCO is just too high to justify for a small team.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am a student and I always develop projects on my own, mainly with Ruby On Rails.
I noticed that even a simple project may become complex if you can't easily rescue deleted code and pass from a version to another. Time Machine backups are not enough.
I would like to use a version control system, but they seem not to be intended for single-user projects. Am I wrong? If so, what policy and software do you use for managing your code?
There is nothing that says you can't use a standard version control system if you are a single user. Doing so would definitely keep you from experiencing some of the more painful problems such as merging files changed at the same time and other conflicts that arise from multiple developers.
Based on this, you could look into any of the version control systems (I believe Subversion is far and away the most popular right now) and pick out the one that will most closely match your needs, or has the interfaces you are most comfortable with.
Distributed version control systems are just for you: look for Bazaar, Git or Mercurial. They are lightweight, local commits are easy and you can always revert to a previous version. With a hosting provider such as GitHub, you can publish your projects, you get backup for free and you can easily share the projects with other potential contributors. Collaboration is easy because merging your changes is also a lightweight operation.
It is definitely a good idea to use version control software, and other project software on your own projects. These tools are not just for team working, although they allow team working. Beyond the obvious reasons for keeping track of your changes to the project it is a good idea to use SCM tools so you are familar with what the industry is using.
Subversion is widespread, and is quite a good bet as it's successfully replaced the earlier and older CVS tool. It relies on a central repository where the code is stored and can be backed up: where I have used SVN for personal projects and small team projects I have backed up to CD. If your project is opensource there are sites like sourceforge that support svn which you can use for hosting.
However as some of the other posters have indicated, a personal project might benefit more from a distributed system: git is increasing in popularity since git-hub has come online and porting efforts to are succeeding. http://git-scm.com/ It is likely that tools like these will grow in popularity over the coming years as they allow a greater number of people to participate on the same code. The idea of one central repository is relaxed giving each developer the ability to version track different designs and only give back to the community the versions they complete.
One of the benefits with using SCM for all projects personal or not, is that a separate server can be set up testing a version of the code. Automated testing on the latest version of the code (using a Continuous Integration Server or similar) can improve the quality of the software you are writing.
Some highly experienced software developers talk about a rhythm where they make incremental changes checking in frequently. Getting into the habit of making small changes which are complete and checking them in: is a good practice to get into for group working.
I would recommend Subversion. It's free and relatively simple, and learning a little about it may well beneficial in the future. It's cross platform and also available on a variety of hosted systems.
See also: https://stackoverflow.com/questions/250984/do-i-really-need-version-control
and: Using Version Control for Home Development?
Subversion!
You can install locally or use a hosted service. The services are nice if you want to switch between computers or use it as an offline backup. http://www.beanstalkapp.com/ has a free plan for personal use.
GitHub (git, not subversion) is also popular but I believe there is a small fee for personal projects.
Use git. It allows you to work without ever needing a server.
There are utilities for the command line and a GUI (older screenshots) too (for linux, windows and OS X).
If you later want to share or publish your project you can easily push it to a site like github.
Even for personal projects, if they become bigger than something you write a few hours, a version control system will be very beneficial.
Here are a few good points:
Many version control systems have good integration with IDEs.
Branching will allow you to experiment without the fear of having to take a long time to revert the changes. The branch can later be merged to the main trunk if needed.
Having a history of changes can be helpful, and tagging will allow setting milestones.
More efficient storage than full backups using regular copying of files.
Extra metadata (such as commit comments) can be attached.
Many version control systems are free!
I personally use a Subversion server running on my system which I access via the Subclipse plug-in in Eclipse, which I find to be very helpful in keeping track of my personal projects.
If you're interested in Subversion, Version Control with Subversion is a very helpful source in learning about the concepts, and how to set up and get started with Subversion.
Version control systems may be a little difficult at first, but it's definitely worth the effort to set up!
I'm very wary of using "always" in any answer I give on SO...
ALWAYS use version control. These days it's free AND easy to do. There's simply no reason ever not to use it. If it's an hour long project...good...it's an hour long project that's in version control now.
My solution has been slicehost(ok...not free), redmine(free RoR bug tracker)git and gitosis. Starting up a new project adds about five minutes on to the front of any coding, but its five minutes well worth it.
Use SVN or Mercurial.
Both very appropriate for "home" usage, I think Mercurial is better for you because by default you'll be creating one repository per project ( oposed to SVN's one "big" repository that stores everything ), so it will be easier to backup individual projects or exchange sources with others if needed.
Both work in command line mode or using explorer-like interfaces ( Tortoise ) or plugins available for the most usual IDE.
I use subversion to manage all my projects. xp-dev.com is a free subversion hosting solution. Also, I think, if you install tortisesvn it installs a subversion server to use locally.
A complete different version control system is dropbox (www.getdrobox.com). It's not (only) intended for source code. It available (with smart OS integration) for Mac, Win and Linux plus private Web Interface.
It may be interesting for you.
One item you will like about git such as using github hosting is that you have a history of changes that you can go to and get the actual code source and thus 'rescue' previous code changes.
You could also use the dropbox approach in just backing up raw code to a folder on the cloud..
I have used both methods for personal projects.
Hosted version control such as beanstalkapp.com is very convenient, but do consider whether you want to hand your source to a third party. You could consider a local repository, backed up online with a solution which encrypts the contents locally before uploading. I do this with subversion, Amazon S3 and JungleDisk.
Bitbucket is an absolute must consideration for personal projects based on:
Free, unlimited, private repositories
Up to 5 users on their free account
Git and Mercurial support
This allows one to quickly spin up a repository without having to pay attention to how many repos are available under a paid source code hosting account.
It also allows projects that will enter the public domain to be simply forked to GitHub, etc.
Version control is always important.
Try a free online SVN like http://beanstalkapp.com/
Do a search and you can find lots of suggestions
I would highly recommend downloading VisualSVN Server. It's a very simple setup and will do exactly what you need.
you can use any version control system that exists just for single user development. as you said, even simple project can become a nightmare if you change something you think is better and it fails. download tortoise snv - it's free and pretty simple to use - and keep your working versions in repository. commit code that works, keep possible small changes (for example refactor one class), build it, test it if it works -> commit, if it doesn't and you don't know why you can allways revert changes and try again.
I will start with a little background for perspective to the question, what legitimate questions can I pose in order to identify the correct source control tool for the real needs of my development teams?
The developers have used ClearCase since an IBM consulting lead project team installed it for use during a large in-house project. During this project the Rational Suite was used to perform tasks, testing, etc. Once this project was completed, only ClearCase was used as a method of storing source code. Unfortunately, at this time ClearCase is used by the developers as a mandatory tool. Until a global project was started at the beginning of 2009, other colleagues abroad used primarily SVN. The global project now requires these developers to use ClearCase Remote Client (CCRC).
I have observed the tool, though very powerful, appears too much for their development needs. The UCM process is implemented on-site, but there is much expressed frustration with the process steps and particularly when using CCRC. The other issue is other development tools require files to be writeable in order to complete development tasks, causing developers to hijack in order to work.
As many companies are now outsourcing and reevaluating all their strategies in order to remain competitive and financially viable, I would like to verify we have the right tool for the right reasons and one that will support not only development activities and needs today, but also for the future. I look forward to gaining a better understanding of this issue.
what legitimate questions can I pose in order to identify the correct source control tool for the real needs of my development teams?
IMO, some of these questions include:
What is the status quo?
Why is the status quo? [Perhaps political: an IBM consulting lead project]
Why might we want to change (what are the incentives)?
What are the alternatives that we could change to?
What would we gain, and what would be lose, by changing to an alternative?
What would be the cost (or effort) associated with changing it?
You can have a better understanding of the potential advantages for the current situation (ClearCase) by reading "What are the basic ClearCase concepts every developer should know ?"
Since CCRC is used to access ClearCase through a RCP interface and a remote Web-based view server, that looks like a cheap alternative to DVCS (Distributed VCS).
That means a possible alternative is to use a free DVCS (Git, Mercurial, ...)
I use UCM for the last 6 years, and find it very useful for large project with multiple inter-dependent "components" (i.e. "coherent set of files") with multiple parallel development.
However, I would not recommend such a heavy methodology (UCM) for small independent projects, with simple linear development life-cycle.
So, to complete the set of questions proposed by ChrisW
What is the size of typical project managed under VCS ?
What is their typology (inter-dependent on one another or rather autonomous ?)
What is the workflow of merge followed by those projects (a simple one might indicate Subversion as a possible candidate, a more complicated one would require more serious tools for heavy merging)
What is the network typology (is a central repository always the best configuration, or a local repo with distribution/replication features would not be more adapted ?)
Cheryl, without attempting to solve your solution - CCRC is obviously an option for your remote developers, but there also exists ClearCase Multisite. If there is a process issue, perhaps providing local rather than remote access to the infrastructure would be a short-term solution, rather than moving SCM.
We have a small 3 developer team that is currently using Subversion for our source control. We expect the team to group to 8 members within the next 6 to 12 months. We are considering changing our source control to either TFS or Mercurial for improved branching. I know TFS is overkill for just branching, but that is the immediate need, and the other features of TFS could aid our team. One of our main concerns with TFS is we've heard that there is a lot of overhead deploying it, especially on a small team. I'm hoping to get some community insight into just how much overhead there may be involved, suggestions to make the process easier, and anything else the community may feel is useful in making the decision to implement.
In my experience, TFS works really well, even for small teams. If your total number of developers is five or less, you can use the relatively affordable Workgroup edition: above that, you'll have to pony up for the real thing, pricing for which is definitely in the 'Enterprise' realm...
The biggest hurdle to starting to use TFS is installing the darn thing: this process seems to be designed for maximum aggravation. (The extent to which the 'designers' of the 2005-to-2008 upgrade 'process' despise their users even manages to go beyond that: fortunately, you'll be able to start with TFS2008 and won't have to worry about upgrading for a while).
If you follow the instructions exactly, you should manage in 2-3 tries, though, and the hardware requirements aren't as bad as they seem. My 3-developer TFS setup runs quite comfortable on a previous-generation Dell laptop with 4GB of RAM.
One of the big advantages of TFS is the VS integration: this works just really, really well, and shelving and branching are implemented in a more straightforward way than with any other systems I've seen.
The process guidance and support in TFS are a bit less polished, but still quite usable. The pluggable support for several development methodologies is quite nice, and several third-party add-ons (for example for Scrum) are available already.
All in all, it definitely won't hurt to try TFS: if you have a MSDN subscription, you probably already have the Workgroup edition as well as a trial of the full version: otherwise, you can downloaded the latter from Microsoft as well.
UPDATE, April 12th, 2010: With the release of Team Foundation Server 2010, the installation and upgrade procedures have improved a lot. A new TFS2010 install shouldn't take you more than a few minutes (assuming you already have an instance of SQL Server 2008 up and running) and even an in-place upgrade of my TFS2008 setup proved to be entirely painless.
Setup of TFS is not too complicated, when you exactly follow the given guide step by step. We are using it on a small team for about one year now and i don't want to miss it any more.
Especially when you use more than one part of tfs like version control and work item tracking and maybe even teambuild, your team will benefit of the tight integration of the seperate parts.
For example, you can link to workitems when checking in code changes.
Then you run an automated build with teambuild and it will automatically update your workitems with the build number.
So afterwards you can see for example in a bug workitem the buildnumber which contains the bugfix.
We also use the sharepoint wiki for documentation and planning although i'm not the biggest sharepoint fan...
The main point is the great integration into the IDE and for workitem tracking the Teamsystem Web Access which allows you to control at least your workitems over a webinterface.
It's been awhile, but I'm thinking that it takes about a half-day to get setup, plus some time reading the manuals beforehand to make sure you know what you're doing. Configuration doesn't take too long -- you need to add all of your developers in as licensed users. Setting up projects is not too hard. I usually set up AD groups to map on the project roles and add those groups to the appropriate roles. I set up a new project in about 1/2 hour.
Note: I don't use any of the features of TFS except source control. If you plan to item tracking, use the project sharepoint site, etc., your mileage will vary quite a bit. I've found that on our projects (2-3 developers) a wiki works just as well for project management.