I'm looking for a CI solution that allows me to do acceptance testing across my app's multiple container-based services. Does CodeShip support that?
I have put in a request to discuss this with their sales dept but their documentation led me to believe this was a better place for the question.
Related
Couldn't find any info on that: does anyone know if SendGrid supports anyhow multiple environments?
I'm talking specifically about webhooks and seems that you can have only one webhook at a time where it would be nice to have separate for dev, stage and production environment while having one template base.
I finally found https://postmarkapp.com/ - so far the only one really supporting multiple environments independently.
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.
Does anyone have recommendations for how to develop on the trigger.io platform with multiple developers? We have an existing source code repository / code review process / staging process, and would like to share the trigger.io build system in a sane way as we foray into mobile.
In particular, we would like several developers to be able to use the build system, with the extra modules enabled when we paid for the service.
There doesn't appear to much documentation or support for this within this trigger.io system...
Support for working in teams is actually a feature we have released recently. We just wrote a blog post that should be enough for you to get started with it: http://trigger.io/cross-platform-application-development-blog/2013/01/15/introducing-projects/
If you have any feedback or run into any issues just ask here or send an email to support#trigger.io.
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.
I look after the merging, deployment and release of Products & Services in the Company I work for. I've slowly moved to this position from development so a lot of this is new to me (I guess!)
We have a deployment process, but no real Release procedure other than telling stakeholders and members of staff about these new services/features/bug fixes shortly before release.
I've heard things about ITIL Release Management, CMDB, versioning and other mumbo jumbo, but are they actually needed or am I going to end up being weighted down in by a load of crap.
The question I guess I'm trying to ask is: what's my first step? Am I making a mountain out of a molehill? How do I shape this department?
Steve
In my opinion following ITIL practices or implementing a CMDB are not necessary but best practices. The most important thing, and first step, in your case, is developing or documented sound processes about what you do. For documentation you can use "programmer friendly" tools like a wiki (MediaWiki, TikiWiki), but if you do not document your practices it is very difficult to implement continual improvement.
If you have already implemented and documented your processes you can study standards and best practices related to your department. ITIL and ISO 20000-1 are standards focused on the quality of services you offer. Services, not ongoing operations. ITIL can provide you with some useful (but not necessary) good practices like implementing a CDMB. If you implement a CMDB correctly your department will have in a database the configuration of the assets you use to provide your services. You will be able to store the configuration of the systems on your clients or what you want. The CMDB can associate its elements with incidents or known errors so the support department could provide the best service to your clients.
CMMI or CRUM are other standards/frameworks that will probably interest you.
About versioning, I think some sort of versioning is a must. GIT or Subversion are good options.
Other tools very interesting in my opinion is some kind of continuous integration, like Jenkins and some ticketing system like Trac or Mantis.