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
when starting with a project and using source control i find it hard to separate the things people are working on so they don't either write duplicate code or think it should be named one thing and so on.
this problem diminishes over time because the general foundation is in place and it's easier to separate the tasks so they don't overlap as much
how do you manage working with source control in the beginning phase?
EDIT:
I can see that it don't really have anything to do with source control, but it gets more apparent when you have source control too. so the question becomes more along the lines of "how do you manage to separate the tasks so they don't overlap too much. I think it's really hard and i haven't really seen much about how to do it.
Well, as far as source control goes, somebody needs to take the lead and set up the basic structure of the project, directories, etc. and communicate it to the team. On projects I work on, this is usually an architect or senior developer, someone who knows the best practices for project organization for the team/company.
With respect to avoiding having multiple people working on the same tasks, that's a project management function; someone needs to determine what tasks need to be done, and communicate it to the team. If you are working in an agile/scrum environment, the team may divide and hand out work items amongst themselves, but in either case you need to communicate to avoid doing the same work twice.
EDIT
To address the issue of multiple people working on the same task, I tend to work on smaller teams, 2-6 people; in this environment, I have had a lot of success with a scrum-influenced approach using the Crystal Clear methodology:
Architect(s)/designer(s) come up with high level design
Architect(s)/designer(s) define iterations/deliveries, the first of which is a "project skeleton" which consists of architectural and back-end components and a thin slice of the app
Lead person breaks up features into 1-3 day tasks/units of work (estimated)
Team meets and discusses priority, timing and dependencies of tasks, and divides up the first set of tasks
The team has brief daily meetings to discuss status/priorities and dependencies, and change direction if necessary
With larger projects/teams, you will almost certainly need someone whose main job is dedicated to tracking status, dependencies and conflicts.
I don't think source control has much to do with the problem of coordinating people's efforts (except that it can catch some "conflicts" when people erroneously try to modify the same files in different ways -- but, that's not as good as preventing conflicts, and even just "preventing conflicts" does not per se ensure that everybody is working on what they should ideally be working right now, in terms of priorities). Coordination is properly managed with practices (and perhaps tools, e.g. Pivotal Tracker -- but, using the right practices is even more important than using nice tools!-) that specifically focus on ensuring coordination. For example, the practices that Tracker is designed to support and enhance, such as story-based iterative planning, and other compatible ones, such as stand-ups, offer ways to meet these needs.
You must be having a base version that everyone is using, check that into the repository, and then make incremental changes to the repository, make sure that everyone works on different part of the code, commit every working change, and resolve conflicts as and when they occur. That is how I would do it.
Related
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 5 years ago.
Improve this question
I ask because my team previously was trying to "do" scrum. We had 2-week sprints, but no releases to go with those sprints! There were several other reasons for this, but one big one was that deployments took too long and were too complicated to do that frequently.
You sort of answered your own question: if deployments take too long, they can't be done frequently and you can't have short iterations, you can't ship the code at anytime, you can't demo progresses at the end of an iteration, etc. So, in your context, not having an automatic deployments was a major impediment that should have been identified and removed very early (through inspection and adaptation).
Back to the question now. Is automatic deployment a crucial practice? Well, as hinted, I'd say it depends on the context: a project with a simple and straightforward manual deployment process can probably live with it. Is automatic deployment a good practice? I think so: an automated process is typically faster, less error prone and humans obviously don't add much value at doing something that can be automated (see also Three Strikes And You Automate).
I'd say yes, it's an essential practice. If deployments are too complicated and taking too long you've got a bigger problem. I think you should sort that out. You have to do them sometime. Doing the work to make it possible to build at will can only help your project.
Being able to claim the "agile" label isn't important; having an automated, hands-off, repeatable build is the point.
Crucial, no, you can get away without it but, as you've found out, everything that you have to do manually will slow down your cycle time.
You should be aiming to automate as much as possible, build, deployment, regression testing and so forth, so that you're not unnecessarily delayed.
The idea of a sprint without a release is an ... interesting ... one. I can't say I've ever seen that tried before :-)
You have to distinguish clearly two things: a shippable product increment and an actual shipment. First is what your team should produce every sprint, second is what may happen with it if it makes business sense.
In other words: what the team produces each and every sprint must be a piece of completely working code, a new increment of whatever it is that you develop. It should be fully built and tested - which is why automatic testing and building environment is a must if you are to do this. However, whether it should be deployed every sprint to production servers and whether this should be automatic is a completely different thing which has nothing to do with the development process itself.
If it is a requirement that you deploy to live production server every sprint (by all means a very good thing to do) then it would probably make sense to automatize it, but whether this process is fully automatic or no shouldn't impede your team's ability to produce fully working code every sprint.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
What is continuous integration and what are its benefits?
This is by far the best explanation I have read so far.
At its simplest, it is simply a mechanism that rebuilds your project whenever a check in is made into some revision control system (CVS etc). This can be extended though to include running tests, all the way through to generating a CD image, mounting it within VMs, installing the product and running full tests on it.
It has the simple advantage of highlighting when code changes break the system as early as possible. Not only does it detect breaks in the code, it highlights who caused the break. This psychological effect is very effective in encouraging good testing prior to check in!
It is the practice of ensuring that all aspects of your software development process are lined up to permit the daily creation of a working version of your product. It is best known as part of Extreme Programming.
This involves things as far afield as build automation, automated testing, daily check-ins, using a source code repository, etc. But the ultimate goal is to help the entire project run according to core Agile Principles so that you deliver early and often. This, in turn, helps you leverage feedback from your users, etc.
+1 for the link to Fowler's page.
Personally, I just found it "nice" to know whenever something didn't compile because we had the poor practice of having a single build (yes, we developed on the production build; we were awesome). We hadn't got the integrated testing phase before I left.
After a while, it did, however, lessen the amount of massive coding changes (compared to the "check in and pray my changes don't conflict" that was rampant). Eventually, most developers started making small changes frequently just to get confirmation from the CC.Net tray icon.
Overall, I found it very comforting to know that we could send out a build immediately if we had to. Had we had just a few smoke tests integrated, I think the stress-level would have been substantially lower.
Just to refresh. At this point there is a huge difference between Continuous Integration (CI) and Continuous Delivery (CD). While most of posts above described CD I'll try to show how CI extends now CD definition. Having all the tools needed to build a package and deploy new version of app automatically is a crucial part of CD. Adding to that test automation (based on three level verification: General Health-check, Detailed Statistics and Historical entries) and a proper governance you're creating a really good piece of CI. Only because of such an extended definition building extraordinary cloud tools is possible. Think about muleESB or esbeetle.com. For both of them CI is something natural although only the second one is supporting both ESB and ETL components.
I hope that it was helpful.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
What tools or approaches would you recommend to a 'one-man team' to keep organized?
I'm doing research that involves a lot of coding, writing hundreds of throw-away perl scripts, C++ binaries that get used until I find some better approach, large amounts of data that gets preprocessed in different ways, where some new preprocessing makes the old way obsolete -- until I find out that the old way was actually better, and so on. My work is inherently a moving target, as I have to try many things out, and often none of it is perfect.
It's not a completely chaotic situation, but it's also far from perfect. Are there general approaches that you would recommend in such a situation? I do use SVN for my code, although not for the different versions of the data because that gets too big. It's hard to keep track of all the scripts and binaries, so I always comment them, write down how I ran them etc. But I'm curious if you have some additional ideas.
(I work on a linux system.)
I'm using a wiki (TiddlyWiki in my case, as that runs absolutely anywhere - all it needs is a browser with JavaScript) as my "engineers notebook". Almost anything goes in there - lists of questions (and later on their answers), procedures (steps by step instructions), notes of what I put where (might work for your "data"), phone numbers (easy to find with a full text search), anything goes.
As my tasks are not that code-heavy, I'm even using it to store code-snippets (mostly SQL statements for me). Using a "real" versioning system is better if you want to keep track of different versions. Other than "use it" I can't offer specific advice for this area.
However, what has been important for me in GTD fashion: Use a simple system for almost everything. That way, the time to search for something and to decide what to put where is cut down.
Keep all your code in your Version Control System, and create build/run scripts for each. Your data you are going to have to carefully file away (since you don't want to put it in SVN).
The other thing I would add would be a wiki so you can make notes quickly about each test/script/application.
why not checkout some opensource projects to see how they organize their code bases?
even though you are a one-man team. it'd be smart to organize your project so it would be easy to add more programmers.
also if you're worried about filesize for data files you might want to checkout git. the index size is usually a lot smaller than that of svn.
Version Control is a must, as others said. Keeping descriptive labels of milestones on Version Control is very very helpful I think.
Also as IronGoofy said, I keep my snippets in my Personal Wiki TiddlyWiki, I uploaded it to my website, so I can access it anywhere, anytime.
As an additional option you may think a Time Tracker application. There are many free Time Trackers. I use ASP.NET's Time Tracker Starter Kit. You can keep evolution of your software, bugfixes, milestones.
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 work for a small one-product one-customer company that is transitioning to a one-product, multiple-customer company. Even though we've had just one customer, we've had different projects with different delivery dates, but for each project we've been able to deliver the latest monthly release which we've kept in a separate code branch in case we've had to deliver bug fixes for that specific release.
Recently, we've acquired a number of new customers and a new problem has arisen: The head branch will typically solve (without breaking functionality) many different customer specific problems, and not all customers want all the changes, but would rather prefer to cherry-pick fixes and features.
Do you have any experience with that situation, and how to handle it practically without being overloaded by testing and work (our monthly release tests take about 3 days of computer time)? And version control wise, how do you manage (I guess cvs will finally have to go...)?
The most simple solution is to cut the product into a core product and each feature into a plug-in. That way, every customer can cherry pick the features they want. But even this solution can quickly overwhelm a small company.
In reality, you usually are in a worse situation: You have a new feature which helps customer A and breaks something for customer B (say, customer B is not ready to modify their database and the new feature doesn't work without the change, so this in fact makes the new version unusable for customer B). If you were big, you could simply ignore customer B.
As it stands, you really need to find a way to convince your customers to move on. The most simple way is money: Tell them how much it will cost them to get a tailor made product and how much all them will save if you can find a solution that suits everyone. Invite your customers over, build a list of changes together and have everyone agree on the plan.
Also, you really must have automatic unit tests, so you can be 100% sure that the product which leaves the house today can't possible be worse than what you sold four weeks ago.
Even with the best version control system out there (for me, that would be git), you can't solve the fan-out you get if you can't get everyone pull into the same direction (except, of course, you can really split each customer into a plug-in).
We have a similar setup of one (fairly specialist) product and multiple (but only the order of hundreds) customers who all want their own pet feature.
As far as I can see you can either go down the 'off-the-shelf' route where your product is non-customer specific, and any features you add are for the good of the product (possibly at customers' request); or you go down the bespoke, consultancy route where every customer has their own unique version of the product.
If your customers all require basically the same product then you should go down the first route and that means all features go to all customers.
Hiding features is easy, maintaining multiple concurrent versions is a nightmare!
A solution which could work if your customers demand to cherry pick their features is to maintain branches for each of them and then very carefully copy relevant changes from your head branch.
This means that your commits need to be as atomic as possible - only fix exactly one issue - and that no changes should go directly into customer branches. But that approach is still very dangerous.
Its possible to use CVS in this situation (altough I would recommend you take a look at other options like SVN).
I worked on some similar projects. and what we did was having a Commom branch, for core features of the system and a "Customer" branch for each variation of the product, this way you can implement specific features and bugfixes of each client and still use the same changes in "commom" to all variations of the product.
This approach takes a lot of configuration management effort though (merging and building), so you might want to have a specific person to handle theses tasks.
EDIT:
Additionaly, you should (if don´t already) have a bug tracker system, in which you should document the client/branch you are working on.
Only support the head/main trunk, unless there is a branch that has a bug fix/feature that is not present in the main line.
I know you said some customers do not want that, but I have seen the end result of the many branch support. You do not want that. It is a nightmare and will cripple your development, product and test teams.
Don't do it.
Be firm.
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 6 days ago.
Improve this question
In an ideal world, our development processes would be perfect, resulting in regular releases that were so thoroughly tested that it would never be necessary to "hotfix" a running application.
But, unfortunately, we live in the real world, and sometimes bugs slip past us and don't rear their ugly heads until we're already busy coding away at the next release. And the bug needs to be fixed Now. Not as a part of the next scheduled release. Not tonight when the traffic dies down. Now.
How do you deal with this need? It really can run counter to good design practices, like refactoring your code into nice, discrete class libraries.
Hand-editing markup and stored procedures on a production server can be a recipe for disaster, but it can also avert disaster.
What are some good strategies for application design and deployment techniques to find a balance between maintenance needs and good coding practices?
[Even though we test a lot before we release, ] What we do is this:
Our SVN looks like this:
/repo/trunk/
/repo/tags/1.1
/repo/tags/1.2
/repo/tags/1.3
Now whenever we release, we create a tag which we eventually check out in production. Before we do production, we do staging which is [less servers but] pretty much the same as production.
Reasons to create a "tag" include that some of the settings of our app in production code are slightly different (e.g. no errors are emailed, but logged) from "trunk" anyway, so it makes sense to create the tag and commit those changes. And then checkout on the production cluster.
Now whenever we need to hotfix an issue, we fix it in tags/x first and then we svn update from the tag and are good. Sometimes we go through staging, with some issues (e.g. minor/trivial fixes like spelling) we by-pass staging.
The only thing to remember is to apply all patches from tags/x to trunk.
If you have more than one server, Capistrano (link to capify.org doesn't go to the intended anymore) is extremely helpful to run all those operations.
One strategy is to heavily use declarative-style external configuration files for the different components.
Examples of this:
Database access/object-relational mapping via a tool like IBatis/IBatis.NET
Logging via a tool like JLog/NLog
Dependency injection via a tool like Spring/Spring.NET
In this way, you can often keep key components separated into discrete parts, hotfix a running application without recompile, and seamlessly use source control (particularly in comparison to stored procedures, which usually require manual effort to source control).
We divide our code in framework code and business customizations. Business customization classes are loaded using a separate classloader and we have tool to submit changes to a running instance of production. whenever we need a change in any class we change it and submit it to a running instance. the running instance will reject the old classloader and use a new classloader insance to load the classes again. This is similar to Jboss hot deploy of EJBs.