I've been researching version control for Shopify but I'm still unsure what kind of approach to take. (I've looked into Beanstalk, Slate, etc.)
We have 4-5 team members who have access to our code but usually it's only 1 person (me) who makes changes. We make a lot of small updates almost daily, and push bigger updates every couple weeks.
We would like to use version control to track changes and to keep backups.
My questions are...
What are you using for Shopify version control?
Do I need version control if it's usually just one person making changes?
Are there any other recommendations for handling code updates and backups?
Is version control a hassle when making a bunch of small changes?
Any help or suggestions would be greatly appreciated.
Shopify development workflow is much different from WordPress or other self hosted projects. However, Shopify has developed some tools and recommendations list to ease the pain. We use Theme Kit, Bitbucket and DeployBot in our workflow.
We use Theme Kit configured with Dev store to work on new features and updates.
Version control is done using Git with Bitbucket. Once the feature branches gets merged to Master, the Master branch is automatically deployed to multiple Shopify stores using DeployBot.
To integrate Shopify with DeployBot you can have a look at Upload your themes from GitHub or Bitbucket to Shopify
Related
I work as part of a small development team (4 people).
None of us are incredibly experienced with version control, but we are required to use Perforce under our company's policies. For the most part it has been great, but we have have kept to a simple process agreed between ourselves that is starting to become less ideal. I was wondering if people could share their experiences of version control working smoothly and efficiently.
Our original setup is this:
We have a trunk, which holds production code as it is now.
Each user creates a development branch for their work, as we have
always worked on separate areas that don't really affect each other.
We develop on Redhat Linux boxes and the code is run from /var/www/html. So we sync to a workspace and copy those files to this path, change the permissions and then perform our changes there. When we want to check in, we check out the files in the workspace, overwrite them with what we have changed and submit (I think this might be our weakest part)
Any changes to trunk will be incorporated if they affect the functionality in question. The code is then deployed for testing.
When testing is complete, we merge the branch into trunk, and then create a release branch from the current trunk this is tested again and then released into production.
This worked fine previously because our projects were small and very separated. Now, however, we are all working on the same big dev branch. Changes have been released since the creation of the dev branch, and more will be made before it is finished.
We are also required to deploy the code for testing in various stages of it's development, and this code needs to be up to date with both the development changes, and any changes that have been made to production.
We have decided at this stage that we will create the release branch at the same time as the dev branch, into which we will merge current Trunk(production) and the current dev branch each time we need a testing version so that it is completely up to date. However, this merge takes a lot of time from the whole team and isn't really working out too well.
I've been told that different teams have different ways of going about things so I'm not looking for a fix for my process, but I would love to hear what setup you use of your willing to share
If you are not particularly familiar with version control and best practices I would suggest utilizing Streams in Perforce. Functionally Streams and Branches are very similar. The difference with Streams is that Perforce utilizes pre-built relationships based on the stream type and gives basic governance (i.e. you can't copy those files to the other stream until you merge).
All the commands CAN be overridden by an admin.
Once you are utilizing streams you can do things a few different ways. You have three types of streams, Release (most stable), Main (stable), and Development (least stable). You can create any hierarchy you like.
I suppose in your case I would have a Mainline, an integration development stream, and then a development stream for each developer to utilize. That way you each have your own playground and can move your changes to the integration stream once they are complete. Those completed changes can then be merged down to the other developer streams.
My company has a project where we need to share an SDK we have developed with initially a limited set of developers, but ultimately all developers, so that they can:
- download the SDK
- submit issues
- browse and post to a forum where other developers troubleshoot issues
- post reference clients that use the code which developers can download, contribute to...
Note: We don't want/need other developers to edit/contribute to the SDK itself. My company will retain control and edit/publish the SDK.
I am seeing sites like GitHub but I'm not sure it's the right fit. Could GitHub meet my needs? Are there other sites that might do this better?
Github provides private repositories for a fee. There's also Bitbucket which also does Git and is now part of the Attlassian suit it provides private repositories for free but the number of users is limited; LaunchPad does the same with Bazaar instead of Git, Microsoft has Codeplex and TFS on the azure cloud, and I'm sure there's a gaggle of providers for other version control platforms.
In short there are many, many options, one of them is sure to fit your needs and budget.
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.
I'm wondering if there is any best practice for maintaining your source code under version control among different companies. In Open Source there is a maintainer, who receives patches, decides on them and applies them. But what about closed sourced projects where different companies get different workloads and just commit them to the trunk and branches? Is this maintainer concept applicable to a project on which multiple companies work on?
You can choose from a wide range of version control systems. (Not only subversion)
With the "versioning" concept you are safe that no one damages the project permanently.
So there is no need for a manual approval process, especially when there are contracts for example between the participating companies.
I'd also set up a commit mailinglist so you have some kind of peer review of changes. So no changes can be done without anyone noticing them.
If applicable set up some kind of continous integration environment to keep the quality up.
I don't understand the question about the branches. The decision whether to use them or not is IMHO not depending on the fact that the commiters are employed in the same company or not.
Its really up to you to decide which workflow works best for the companies involved. Subversion has the ability to add permissions to your trunk and branches allowing you to lock down certain parts of your repository to people who are "trusted" with merge access to trunk. You'll need good communication amongst the companies. Using the open source Trac provides a wiki, integrated RSS feeds of the commits to the project and code browser.
Usually, each site works on its dedicated branch and can import the other remote site branch, to decide what to integrate in its own work.
But if a site need to work directly on the other site branch, one possible practice is the concept of branch membership which allows only one site at a time to work on a given branch.
(not sure it is possible with SVN though)
That allows for two remote site (with a large time shift) to work on the same task in a tightly integrated manner.
My recommendation : subversion, with that configured you give away a url and then checkout, update, get things done and when you guess that the project is ready, snapshot and deliver.
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.