in my company we are doing an investigation over NetSuite Deployment of new features to Live Environment.
Till this day, there was only 1 developer who was doing all the development and customizations in NetSuite. Problem is that nobody anticipated that one day there will be a whole development team and regular releases of new features in NetSuite.
Till this day all deployment from SandBox was done manually by that single developer who did all customizations. But this not acceptable with multiple developers doing development.
Can anyone tell me possible solutions of Automatic Deployment? Right now we are investigating Bundler as a possible solution, but we would like to see if there are more solutions like that to compare.
Thank you very much.
You are in the right track, you need suitebundler. The way it works is you 'package' your scripts, custom fields, custom records, etc. from the sandbox account and you make it available to other netsuite account (or public if that is intended).
Yes when you refresh your sandbox, everything gets wiped out in your account if it's not in your production account.
Related
What is a good way to track deployments of our code base? I would like to be able to see when a version was deployed on a specific server, who released it, what issues were solved by it, etcetera.
Currently we have a deployment tool that generates an issue in our issue tracker with all this information. This makes it easy to link the release issue against related issues, but it also pollutes our issue database.
We also want to start with Continuous Integration internally, which would mean there would be a ton more release issues.
Are there better ways of tracking releases?
Our technology stack is PHP (Symfony2) using Phing as a build system, a custom, web-based deployment tool, Mantis for bugtracking and Bitbucket for repository hosting.
You can use something like Beanstalk or dploy.io to deploy your apps. It will give you an ability to manage deploy permissions, see a timeline of all deployments (who deployed what and when), trigger deployments with a single click and notify your team via email and integrations when something is deployed.
You can get an idea from this screenshot:
http://cl.ly/image/3C1v1w2C3K2v
P.S. I work at Wildbit, company that makes both products.
You should check out my company's product BuildMaster, it was designed to solve every problem you've listed.
At this time we do not yet have the first-class integration with Mantis, but it can be added pretty easily via extensibility in the same way as the other bug/issue trackers we integrate with. It could be either built by your team if you are interested in that or our team contingent on an Enterprise edition purchase.
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.
I want to implement something simple like /System/Workflows/Sample Workflow with the small addition of having multiple publishing targets (staging web and production web environment), so instead of the Approved state with the final checkbox set, i want to modify it to two states;
Approved for Staging
Approved for Delivery
only the Approved for Delivery should be final. I want to set a PublishAction for each of them but i don't know how to set the publishing target?
This is a very common issue that ultimately ties to how Sitecore works. Your question seems to indicate that you understand that only one state in workflow should be final -- that's great that you see that. There are ways to do this, but I would say some of them are not best practice. Also, as divamatrix mentioned, there are other custom approaches.
Deviate from best practice and mark Approved for Staging as Final and Approved for Delivery as Final. I do not recommend this. I'm mentioning this is a solution so you can see the full circle of what you can do. The issue with this is that if you log in as an admin, you can potentially publish to any target as well as other things. Generally, this is just not a good idea.
As divamatrix mentioned, there's a custom publishing provider by Alex Shyba on the topic. The article linked is the older approach. There's actually an update to that solution which seems to be the next best thing. That solution includes a custom workflow provider and some updates to the targets in Sitecore.
Another option is to de-couple workflow from publishing, which might sound drastic, but in theory makes sense. Basically, force content to go through all of worflow, then have a publish-only role that is the only one that can publish the content. From there, they can publish to the staging site and get stakeholder approval before publishing live.
UPDATE: As of Sitecore 7.2, there is a built-in mechanism to publish to a pre-production target.
Here's a link to everything you need to know: Alex Shyba's blog entry on custom publishing targets. I can verify that it all works because I've currently got a site in production that uses exactly what Alex outlines. Let me know if you have questions.
UPDATE: As Mark points out, this link is indeed an older solution. It will work, but Alex's part 2 link as posted by Mark is a better solution.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I work as an in-house developer for a manufacturing company. We make software for the manufacturing process, not really control software, more like process flow.
We are using a Scrum process to develop the software, albeit tailored to fit with our team and environment, and this is working quite well. We're coming to the end of a sprint and the software is at a stage where the product owner wants to deploy it.
Previously, i.e. before Scrum, we would have deployed the software. Now I feel like we have developed the software, we've passed all the user-defined/agreed release tests and demonstrated the software to the PO with a simulator, we have achieved our goals. We are ready to provide deployment support but I don't think it should be our responsibilty to deploy.
What are other peoples experiences? Should the dev team do the deployment or should we just hand over the completed software to the PO and provide support?
Summing up
A lot of great responses, thanks. The question may seem like I'm trying to squirm out of work or responsibility, maybe I am a little ;o) What I'm more interested in is other peoples processes. The problem we face here is that if the dev team deploy the software then we end up providing 24/7 support to production for the software. No prob, except there are only two of us. So, to allow us to get back to developing software rather than providing support all the time I thought it might be helpful to get the "IT" team involved in development process. Hopefully this will get the 'buy-in' and then allow them to deploy and provide first level support. We also have a plant in Mexico and its difficult for the dev team to go and deploy there, it makes more sense for the local support to do it, with guidance/advice from the developers.
Just to let you know, the IT engineers did deploy the software, with guidance/advice from dev. Its gone quite well, the customer is happy - he's got increased value for his software, and isn't that what its all about?
I don't think Scrum as a methodology addresses deployment responsibility. I've worked for large organizations with a deployment team completely independent of the development team. I've also worked at small organizations where the development team handles deployment. Ideally, the deployment team is separate from development, but it would almost never be the PO (which I assume means product owner). The PO usually signs off, but is not usually the best choice for handling deployment.
Who gets the call at 3am when the software isn't working or a system died? If it's the dev team then by all means expect to own the deployment (since you own production).
Best practice for organizations that can support is to provide the Operations group with deployment instructions and good wishes. Bottles of scotch help too.
If your production controls are lax, than tighten them up. A book like "Visible Ops" is a great guide to getting things under appropriate levels of control in the appropriate hands.
I'm a dev mgr with responsibility over multiple products. I have my dev teams produce builds of deployment artifacts, such as .war files, that can be simply deployed to Tomcat web server using it's manager interface or web service API. The configuration for the app is all set and self-contained within the .war file. Hence it is straightforward for the person doing deployment to just take it and "drop it in", so to speak.
If we don't get this level of ease of deployment to where deployment can be completely decoupled from the development team, then I view that as a failure on the dev team's part to adequately do their job.
The person doing deployment proceeds to release a given product to numerous customer sites - that's not a productive activity for me to let developers be doing - they have products to design and create as that is their specialization expertise.
In our organization the deployment responsibility also overlaps with the first tier production support responsibility.
We practice some scrum methodology but I've never viewed this issue as tied to software development process methodology, per se.
the software process is not completed until the working software is in the hands of the users that need it - otherwise it's just "shelfware"
if there is no one else to be responsible for deployment and configuration management, then you're it ;-)
I would think as an "In-house" developer it would be your responsiblity (unless there is a specialised deployment team) to deploy the new software whereas if you were from an external company then it would be upto them to deploy it themselves, unless specified in the contract.
Depends on the project and what "deployment" means for you. Since I am a web developer, deploying mostly .NET applications with an Sql Server database, I always prefer the deployment be done by a release manager or deployment manager. Why? Because separation of jobs ensures that problems are caught when they need to be.
The developers job should be to provide the required objects or instructions on how to deploy, then someone else deploys to a staging environment. If something goes wrong during deployment to staging, the deployment instructions are corrected until the deployment to staging works flawlessly. That way, there will hopefully be no mistakes when the same deployment script is used to move the code to production. In other words, not only must you test your code but also the deployment script.
of course, in the real world, this doesn't always happen because of personnel issues, but this would be my ideal.
Seems fairly simple to me- if not you, then who? Would actual deployment responsibility have fallen to some other team before you started using Scrum? If not, then I don't see why Scrum would change that.
If the dev team was providing the deployment before scrum, they should continue to do so, unless Management has specifically said that someone else should do it. If managment hasn't said, then they haven't really thought about it, and just expected that it would happen magically, like it always has.
If you don't like that, bring it up with management, but do the work until told differently.
I think you have to man-up and deploy the software. unless you are working in an organization that has some kind of serious data security issues and or SOX issues with allowing the unclean to deal with the production end of things.
I agree with the first comment - SCRUM has nothing to do with it. In fact I would think it's far better for you to be deploying as you'll know first hand how well things are working and be right there to get feedback from those users.
In the past my development team we have mostly done waterfall development against an existing application and deployments were only really done towards the end of a release which would normally result in TEST, UAT, PROD releases normally only consisting of three to five releases in a two month cycle.
A release was an MSI installer, deployed via Group Policy.
We have now moved to a more agile methodology and require releases at least once per day for testing, some times more often.
The application is a VB6 app and the MSI was taking care of COM registrations for us, users do not have elevated privileges on their machines.
Does anyone have any better solutions for rapid deployment?
We have considered batch/scripted installs of the MSI, or doing COM registrations per file, both using CPAU for elevated privileges, and ClickOnce. Neither of these have been tested yet.
Edit: Thanks for suggestions.
To clarify, my pain point is the MSI build / deployment process takes a long time can take up to two hours to get the new build on to the testers desktops. The testers do not admin rights on their machine (and will not get them) so I am looking for a better solution.
I have played around with ClickOnce, using a dot net wrapper which starts up the application and has all the OCX/DLL vb6 assemblies as isolated dependencies, but this is having issues finding all the assemblies when it starts up, or messages to that effect.
CruiseControl and Nant are probably your best bet for builds with flexible output. But Rapid Deployment?
My concern is that you are looking at the daily builds in the wrong way. The dailies do NOT need to be widely deployed. In fact, QA and Development are the only ones who should care about the builds on a day to day basis. EVen then, the devs shouldn't be out of sync ;).
The customer team should only recieve builds at the end of a iteration. That is where you show them what you have done and they provide feedback and you move forward from there. Giving them daily builds could cause a vicious thrashing that would kill your velocity.
All that being said, a nice deployment package might be good for QA. But again, it depends on how in step they are with your development iterations. My experience, right or wrong, is that QA is one iteration back testing the deliverables from the last iteration. From that point of view, they should be testing with the last "stable" release as well.
Is this something you can do in a virtual machine? You could securely give your testers admin rights on the virtualized system and most virtualization software has some form of versioning so you can roll back to a "good" state if something goes wrong. I've found it to be very useful for testing.
I'd recommend ClickOnce with the option to update on execution. That way only people using the software receive and install the updates.
You could try registry-free COM. See this other question. ActiveX EXEs still have to be registered though.
EDIT: to clarify, using registry-free COM means the OCX/DLL components you mention don't need to be registered. Nor do any OCX/DLL components they use. You can just copy the whole application directory onto a tester's machine and it will work straightaway.
If I understand your question correctly, you need admin rights to install your product. I see three options:
1) Don't install to the tester's desktops. Get some scratch testing machines (as dmo suggested, VMWare might help) that you can safely give them admin rights to. This may mean giving them a test domain and their own group policy to edit.
2) Build a variant that doesn't require MSI installation, and can be executed directly. Obviously your testers would not be testing the deployment and installation process with this variant, but they could perform other tests of the product's functionality. I don't know if this is possible with your product; it would certainly be work.
3) Take your agile medicine: "[prefer] responding to change over following a plan". That is, if denying admin rights to your testers is interfering with their ability to do their jobs efficiently, then challenge the organization to give them admin rights. (from experience, this will mean shifting to #1, but it might be the best way to make the case). If they are expected to test the product, how can they not even be allowed to install it in the same way a customer would?
If the MSI deployment is taking velocity out of agile testing, then you should test MSI deployment less regularly.
Use XCOPY deployment wherever possible, using .local for COM components. This can be a problem with third party components. As third party components are pretty stable, you should be able to build a custom MSI for these, install them once and be done with it.
You should try an automated build/deploy process or script that you can manually run. Try Teamcity or CruiseControl. Good luck!
I'm not sure just precisely what your pain point is.
You specifically mention registration of VB6 COM objects. Does the installer sometimes fail because of that?
Is it that the installer works but people don't know to install the new build so they are more often than not reporting bugs on an old build?
If the former, then I suspect the problem to be that VB6 was very likely to play fruit basket turnover with the GUIDs when rebuilding the solution. Try recreating your public interfaces in MIDL and have your VB6 classes implement those interfaces.
If the later, then try Microsoft's SMS product. No, it has nothing to do with cell phones. If all the user's aren't on the same domain, then you will have to build an "auto update" feature into your product. Here is a third party offering that I've heard of but never used.
I'm using SetupBuilder (http://setupbuilder.com/products_setupbuilder_pro.htm) for all my builds. Very extensible. Excellent support.
Not sure exactly if it fits your needs, but this kind of post on the forums, "Installing as a limited account user (non-admin) on XP" (http://www.lindersoft.com/forums/showthread.php?t=11891&highlight=admin+rights), makes me think it might be.