our small team of 2 people recently got upgraded to 5, which means we should introduce a bit more infrastructure around our project in order to work efficiently together. Its a university research project.
How much administrative effort is it to run
Gitlab
Jenkins
A Release Server
on a rented machine, in comparison to a SaaS solution e.g github with Travis ?
Unfortunately nobody in our (quite academic) team has practical experience with that. I know the setup can be done fast, but how time consuming is it to keep the stuff running. Are there other concerns we might be missing?
Of course we would like to mainly work on the project itself, but since the toolstack keeps growing by time we are not sure if a SaaS solution is what we need.
With these inputs be ready to spend from one to several weeks of one from the five.
Instead you might want to check which leading hosting companies provide free services for open source or educational projects.
Related
I've been developing a web app locally on my local MAMP computer for the last few months. Now I am ready to launch it while continuing to add enhancements/fixes. So, I am wondering what is a good way to implement a development AND production server in order to efficiently manage updates, prevent overwrites, and seamlessly add other developers into the workflow. I also want something that has a minimal learning curve for me. Personally, for whatever reason, I've never been able to fully grasp version control systems like Git or SVN so I am hoping for an easier solution until I am able to invest more info the business.
As I see it, the options that I have are:
Spend more time learning Git before launching. And hoping that I don't break anything while further developing my app.
Buy two hosting accounts. One for Dev and one for Prod, where only I can do the deployments into Prod. I suppose I'd have to keep track of all files we've modified in a spreadsheet that are deemed ready for deployment.
Editing right on the FTP (no Dev server).
Are there any other options that you can recommend? I've heard that there are some new types of Web Hosting companies that can do the heavy lifting...
While personally, I have had good experiences using svn/git for multi-developer websites, I can understand your reticence to start relying on something you are not entirely familiar with. Unfortunately, I do believe that is your best option, but failing that, you might try using subdomains. My former employer would create test area on the disk and point beta.thedomainname.com at it. When bug fixes or upgrades were complete and verified to be working in the beta directory, the entire directory would be copied over to the live domain. Not the most elegant solution, but it worked. It certainly is cheaper than buying two hosting accounts.
So I've been a developer on a one man team for a few years now. I came to recognize the benefit of separating all of the design, html, and css work into the hands of the more gifted individuals, so I started a business, made up of other long-time 1 man teams who were limited to static websites (that looked gorgeous). You can imagine what comes next.
We've been using Zend Framework (PHP applications for most applications, which separates most of the view code from business and data layers, but occasionally one of the designers or front-end guys has to tinker with a model or view script, and I'm starting to have coordination nightmares for who is updating what files and when so we don't overwrite anyone's important changes in the dev environment. (obviously waiting for stability before production deployment)
I work with NetBeans on my local, while the others use dreamweaver. What I'm looking for is a tool that can manage file versions on the dev server, allowing check in/check out, so nobody is working on the same file at the same time. (or better yet, merges changes)
Any suggestions on a good tool for this? Would a CI tool be better or a VCS tool? The only other option I can think of is to work directly on a development server, deploy to a simprod environment, than after testing, move to prod, but I like being able to develop behind a firewall before putting something on the internet. Any recommendations would be helpful.
Thank you.
You are looking for git. Perfect for managing versions and branches, deploying to the dev or prod servers, pretty much anything you can throw at it.
First I should disclose I only manage vendor relationships and lack deep technical knowledge.
I just had a conference call with one of our sub-contractors who has asked me to sign off on a PO for 4 different servers (one for Jenkins another for Github, a third for Puppet and a fourth as a test box).
The technical architect seems quite defensive when I ask him questions. I know its not my job to question his ability but I do have a budget to manage and I am concerned they have over- engineered this (or at least the 3 products they have mentioned seem to overlap alot).
Would someone be so kind as to clearly explain to me the role each one plays.
I would also appreciate a second opinion as to whether they really need 4 servers and whether some of the technologies mentioned could co-exist on the same servers. (i.e could Jenkins, Github and Puppet all live on a single Ubuntu server ?).
The 4 tools do not overlap. They interact and complement altogether.
GIT is the source control tool. You store all the history of programming there. It's the dev blackbox.
Jenkins is the continuous integration tool. It will use GIT to get the latest version of the code ( or the testing version or the pre-production version ) to test it against the test patterns you defined.
Puppet seems to be a server administration toolbox.
Honestly, it depends on your project. If it's a huge app that requires heavy building cycles, then jenkins will be better off on its own server, so that people can still work normally with other services.
I believe Jenkins/Puppet could be on the same server. Or so could be Pupper and GIT ( git is very low resource ).
The testbox sounds ok. But I think that the GIT box could also be served as a testbox.
I think you could cut that server needs by 2. But again, it depends on the size of your project. If it's a big project, play it fair and let them do it. Even if the server split is a little strange, it could be necessary.
But frankly I think you don't really need that.
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.
Most of the work I do is with what could be considered enterprise Web applications. These projects have large budgets, longer timelines (from 3-12 months), and heavy customizations. Because as developers we have been touting the idea of the Web as the next desktop OS, customers are coming to expect the software running on this "new OS" to react the same as on the desktop. That includes easy to manage automatic upgrades. In other words, "An update is available. Do you want to upgrade?" Is this even a realistic expectation? Can anyone speak from experience on trying to implement this feature?
At my company we have enterprise installations ranging into the thousands of seats. If we implemented an auto-upgrade, our customers would mutiny!
Large installations have peculiar issues that don't apply to small ones. For example, with 2000 users (not all of whom are, let us say, the most sophisticated of tool users), tool-training is a big deal: training time, internal demos, internal process documents, etc.. They cannot unleash a new feature or UI change without a chance to understand how it fits in their process and therefore what their internal best practices are and how to communicate that to their users.
Also when applications fail, it's the internal IT team who are responsible. Therefore, they want time to install a new version in a test area, beat it up, and deploy on a Saturday only when they're good and ready.
I can see the value in making minor patches more easy to install, particularly when the patch is just for a bug-fix and not for anything that would require retraining, and if the admins still get final say over when it's installed. But even then, I don't believe anyone has ever asked for this! Whether because they don't want it or they are trained to not expect it, it doesn't seem worth it.
Well, it really depends on your business model but for a lot of applications the SaaS model can end up biting you. It's great for a lot of things but for some larger applications the users are not investing as significant amount up front and could possibly move to something else before you've made any money.
See
http://news.zdnet.com/2424-9595_22-218408.html
and here
http://www.25hoursaday.com/weblog/2008/07/21/SoftwareAsAServiceWhenYourBusinessModelBecomesAParadox.aspx
for more information
One of the primary reasons to implement an application as a web application is that you get automatic upgrades for free. Why would users be getting prompted for upgrades on a web app?
For Windows applications, the "update is available, do you want to upgrade?" functionality is provided by Microsoft using ClickOnce, which I have used in an enterprise environment successfully -- there are a few gotchas but for the most part it is a good way to manage automatic deployment and upgrade of Windows apps.
For mobile apps, you can also implement auto-upgrades, although it is a little trickier.
In any case, to answer your question in a broad sense, I don't know if it is expected that all enterprise apps should make upgrading easy, but it certainly is worth the money from an IT support standpoint to architect them to allow for easy upgrading.
If you're providing a hosted solution, I wouldn't bother. Let the upgrade happen silently (perhaps with a notice that you did it). If you're selling an application that's hosted on their servers, let the upgrade decision be made by a single owner, not every user of the app.